全て想像ですが
読み方はケーツと読みます、半端ねーてす、あるいは半端ネース
ケツが扱う最小単位がPodで1つの機能を持つ（Podは1つ以上のコンテナを含む）
ReplicaSetは複数のPodを組み合わせてアプリを実現する（Podの数の管理機能）
DeploymentはReplicaSetを管理、アップデートの際は新規ReplicaSetを作成してバージョン更新を行う（Podのデプロイ管理機能）
ServiceはDeploymentに対してIPアドレスやLBを設定してサービス提供する（Podへのアクセス管理機能）
クラスターはServiceが複数動く環境、少なくとも1つのMaster(node)と複数のNodeから構成され
Nodeはコンテナを動かす為のサーバ、MasterはNodeを管理しスケジューリングやオートスケールを行う
（非マネージドなら単一障害点にならないようマルチMaster3台が一般的）
cluster > namespace > node x workload (pod, <複数pod:deployment, job, statefulset>, <全てのnodeにpod:deamonset>)
namespaceは論理的な分離、node poolは物理ノード・スケーリング管理
読み方はケーツと読みます、半端ねーてす、あるいは半端ネース
ケツが扱う最小単位がPodで1つの機能を持つ（Podは1つ以上のコンテナを含む）
ReplicaSetは複数のPodを組み合わせてアプリを実現する（Podの数の管理機能）
DeploymentはReplicaSetを管理、アップデートの際は新規ReplicaSetを作成してバージョン更新を行う（Podのデプロイ管理機能）
ServiceはDeploymentに対してIPアドレスやLBを設定してサービス提供する（Podへのアクセス管理機能）
クラスターはServiceが複数動く環境、少なくとも1つのMaster(node)と複数のNodeから構成され
Nodeはコンテナを動かす為のサーバ、MasterはNodeを管理しスケジューリングやオートスケールを行う
（非マネージドなら単一障害点にならないようマルチMaster3台が一般的）
cluster > namespace > node x workload (pod, <複数pod:deployment, job, statefulset>, <全てのnodeにpod:deamonset>)
namespaceは論理的な分離、node poolは物理ノード・スケーリング管理
■ケツリソース一覧
Node：Kubernetes クラスタで実行するコンテナを配置するためのサーバ
Namespace：Kubernetes クラスタ内で作る仮想的なクラスタ
Pod：コンテナ集合体の単位で、コンテナを実行する方法を定義する
ReplicaSet：同じ仕様のPodを複数生成・管理する
Deployment：Replica Setの世代管理をする
Service：Podの集合にアクセスするための経路を定義する
Ingress：Service を Kubernetes クラスタの外に公開する
ConfigMap：情報を定義し、Podに供給する
PersistentVolume：Podが利用するストレージのサイズや種別を定義する
PersistentVolumeClaim：PersistentVolumeを動的に確保する
StorageClass：PersistentVolumeが確保するストレージの種類を定義する
StatefulSet：同じ仕様で一意性のあるPodを複数生成・管理する
Job：常駐目的ではない複数のPodを作成し、正常終了することを保証する
Cronjob：cron記法でスケジューリングして実行されるJob
Secret：認証情報等の機密データを定義する
Role：Namespace 内で操作可能な Kubernetes リソースのルールを定義する
RoleBinding：Role と Kubernetes リソースを利用するユーザーを紐づける
ClusterRole：Cluster 全体で操作可能な Kubernetes リソースのルールを定義する
Cluster RoleBinding：ClusterRole と Kubernetes リソースを利用するユーザーを紐づける
Service Account：Podに Kubernetes リソースを操作させる際に利用するユーザー
流れ
Dockerfile(設定)とアプリをdocker build/pushし
DockerレジストリにDockerイメージを作成
GKEにデプロイ(deploymentファイル.yml/serviceファイル.ymlをkubectrl create/apply：manifest)
レプリケーションコントローラ:Pod数、オートスケールをdeployment fileで設定
サービス定義：ノードのproxyデーモンが複数Podに負荷分散
ノードがクラスタ内のPod同士に振分けるクラスタIP
LBが振分ける外部IPを設定
K8s
クラスタリング（複数サーバを束ねる）
コールドスタンバイ、ホットスタンバイ（フェイルオーバ）
オーケストレーション…NW、Storage、スケジュール、IP、ルーティング、負荷分散、監視、デプロイ（ローリングアップデート）
構成
マスターサーバ（コントロールプレーン）←kubectrl
etcd（DB:kvs形式のconfig=マニフェスト、デプロイメントとサービス等を記述）
etcd（DB:kvs形式のconfig=マニフェスト、デプロイメントとサービス等を記述）
レジストリサーバ（コンテナレジストリ：GCSに保存）
↓
↓
ワーカーノード＞Pod＞コンテナ(webサーバ)、コンテナ(ログ収集)、仮想NIC
ワーカーノード、ワーカーノード…
GKE
コンソールで設定＋kubectrl
コンソール：GCE、ストレージ、タスクキュー、BQ、cloudSQL、cloudDataStore、cloudソースレポジトリ、StackDriverLogging、StackDriverMonitoring、StackDriverTrace、CloudPlatform、BigTable、Pub/Sub、サービスコントロール、サービス管理
※コンソールだけでkubectrl無しでイケそう
クラスタ作成＞ワークロードでコンテナデプロイ、あるいは直接デプロイで簡易でイケる
クラスタ作成をすると一般公開で承認NW、あるいは限定公開、はたまたIP範囲とか詳細を決められる
※コンソールだけでkubectrl無しでイケそう
クラスタ作成＞ワークロードでコンテナデプロイ、あるいは直接デプロイで簡易でイケる
クラスタ作成をすると一般公開で承認NW、あるいは限定公開、はたまたIP範囲とか詳細を決められる
■流れ
GKEでクラスタを作成
Kubectrlをインスコ
KubectlでPodを立ち上げ＞Deploymentができる、複数Podの起動も
Kubectlでサービス公開設定
【GCP入門編・第7回】Google Container Engine (GKE) での Docker イメージの立ち上げ方 | 株式会社トップゲート (topgate.co.jp)
サービスアカウント作成
ネームスペース、kubeサービスアカウント作成
Yamlで機能を宣言しKubectlでデプロイ
時間の掛かっていた処理をクラスタ構成で並列処理させて早く終わらすとか
ケツのツールを入れるとか、例えばArgoワークフローでデプロイ/デリバリー/バッチスケジューラを動かす
DAG：有向非巡回グラフのやつ
＝＝＝＝＝＝＝＝＝
helmを入れる(kubectrlを使うローカルに)とチャート記述でデプロイができる
テンプレートがありマニュフェスト記述からkubectrlあたりのデプロイを省力化できる
＝＝＝＝＝＝＝＝＝
masterとworkerで構成され冗長化を考慮すると最低master3台、worker2台～のサーバ要るのでマージドが楽
コンテナにはストレージを置かず外部に持たせた方が良いかも（ステートレスでファイルを保持しない）
DBはK8s上でなくマネージドサービスを使いたい
＝＝＝＝＝＝＝＝＝
VMからOSを抜いてアプリを入れたものがコンテナ、ドッカ―がOS以下を手配
Dockerがコンテナを管理、k8sがそのDockerをオーケストレーション
【GCP入門編・第7回】Google Container Engine (GKE) での Docker イメージの立ち上げ方 | 株式会社トップゲート (topgate.co.jp)
サービスアカウント作成
ネームスペース、kubeサービスアカウント作成
Yamlで機能を宣言しKubectlでデプロイ
Pod(論理ホスト/インスタンスみたいな)
一意のIPが自動的に割り当てられる、Pod間はIPで通信
Pod内のコンテナはlocalhost:ポートで互いに通信、コンテナ間で共有するストレージ
Podを直接作成は非推奨
CPU/メモリの最小と最大を設定
k8sのsecretリソース(≒SA key)はPw/Oauthトークン/SSH key等を含むオブジェクト(base64エンコード生)
使う方法3種類：コンテナにマウント、コンテナの環境変数、Pod生成時にケツがpull
＝＝＝＝＝＝＝＝＝時間の掛かっていた処理をクラスタ構成で並列処理させて早く終わらすとか
ケツのツールを入れるとか、例えばArgoワークフローでデプロイ/デリバリー/バッチスケジューラを動かす
DAG：有向非巡回グラフのやつ
＝＝＝＝＝＝＝＝＝
helmを入れる(kubectrlを使うローカルに)とチャート記述でデプロイができる
テンプレートがありマニュフェスト記述からkubectrlあたりのデプロイを省力化できる
＝＝＝＝＝＝＝＝＝
masterとworkerで構成され冗長化を考慮すると最低master3台、worker2台～のサーバ要るのでマージドが楽
コンテナにはストレージを置かず外部に持たせた方が良いかも（ステートレスでファイルを保持しない）
DBはK8s上でなくマネージドサービスを使いたい
＝＝＝＝＝＝＝＝＝
VMからOSを抜いてアプリを入れたものがコンテナ、ドッカ―がOS以下を手配
Dockerがコンテナを管理、k8sがそのDockerをオーケストレーション
複数台でまとめたクラスターで故障があっても切り替え可用性を保つ
そのクラスターをnamespaceで分割し複数チームで利用することも可
稼働中にサーバ追加のスケールをしたりロールバックできる
podにIPを割り振ったり、DNS名を振ったり、負荷分散したり
自動デプロイでコンテナイメージをサーバ群へ展開する
Dockerのホスト管理、コンテナのスケジューリング、ローリングアップデート、死活監視、ログ管理等々
Externalname>LoadBalancer>NodePort>ClusterIP
マネージド以外ならk8s用にユーザ管理も必要
Dockerはアプリイメージという感じ、それらを束ね管理するのがケーツ
Kubernetesとは何かを図でわかりやすく解説！Pod、Na…｜Udemy メディア (benesse.co.jp)
ケツは3か月ごとにアップデートされ知識もアップデート必要だし、バージョンによって機能が変わり古いコードが動かないこともあり大変らしい
＝＝＝＝＝＝＝＝＝
↓実際のアプリがないとイメージ沸かん
クイックスタート: 言語に固有のアプリのデプロイ | Kubernetes Engine ドキュメント | Google Cloud
コンテナ化されたウェブ アプリケーションのデプロイ | Kubernetes Engine | Google Cloud
Cloud buildを使用してアプリをコンテナイメージにパッケージ化
GKEでクラスタを作成、コンテナイメージをクラスタにデプロイ
↓手始め？
GKEでnginxを外部アクセス可能にするまで - Qiita
Kubernetesでのコンポーネント間の通信をまとめる - Qiita
GCP におけるコンテナ入門 ~Kubernetes の何がすごい！？ | クラウドエース株式会社 (cloud-ace.jp)
GKE
これはいいかも
Objectsについて知る - オーケストレーションツール (y-ohgi.com)
GKEクラスタをコンソールで作成
NATを作成
Cloud shellを起動
=========================
=========================
●DAGを使う
Kubernetes ネイティブなワークフローエンジン Argo Workflows | 豆蔵デベロッパーサイト (mamezou-tech.com)
Argo公式マニフェストが長すぎる？argo-helmでやるか
argo-helm/charts/argo-workflows at main · argoproj/argo-helm · GitHub
Quick Start - Argo Workflows - The workflow engine for Kubernetes (argoproj.github.io)
gcloud builds submit --pack image=gcr.io/bangboo-run/unco ならDockerfile不要らしい
ケツは3か月ごとにアップデートされ知識もアップデート必要だし、バージョンによって機能が変わり古いコードが動かないこともあり大変らしい
＝＝＝＝＝＝＝＝＝
↓実際のアプリがないとイメージ沸かん
クイックスタート: 言語に固有のアプリのデプロイ | Kubernetes Engine ドキュメント | Google Cloud
コンテナ化されたウェブ アプリケーションのデプロイ | Kubernetes Engine | Google Cloud
Cloud buildを使用してアプリをコンテナイメージにパッケージ化
GKEでクラスタを作成、コンテナイメージをクラスタにデプロイ
↓手始め？
GKEでnginxを外部アクセス可能にするまで - Qiita
Kubernetesでのコンポーネント間の通信をまとめる - Qiita
GCP におけるコンテナ入門 ~Kubernetes の何がすごい！？ | クラウドエース株式会社 (cloud-ace.jp)
GKE
これはいいかも
Objectsについて知る - オーケストレーションツール (y-ohgi.com)
GKEクラスタをコンソールで作成
NATを作成
Cloud shellを起動
k8s用の認証情報を取得
$ gcloud container clusters get-credentials <standard-cluster-1> --zone asia-northeast1-a
k8sオブジェクトを表示
$ kubectl get all
nginx dockerイメージを起動
$ kubectl run <handson> --image=nginx --port 80
LBを作成しトラフィックを流す設定
$ kubectl expose deploy <handson> --port=80 --target-port=80 --type=LoadBalancerサービスを表示（LBを見る）
$ kubectl get service
レプリカセットを表示
$ kubectl get replicaset
ポッドを表示
$ kubectl get pod
ポッドを削除
$ kubectl delete pod <handson-86f796b8b7-m68sr>
nginxコンテナ3台を立てる
$ kubectl run <handson-2> --image=nginx:1.14 --replicas=3
ポッドの詳細情報を表示
$ kubectl describe pod <handson-2-85dfb7fd88-wr58c>
デプロイメントを表示
$ kubectl get deployment
dockerイメージのバージョン変更
$ kubectl set image deployment <handson-3> <handson-3>=nginx:1.15
デプロイメントのレプリカセットの履歴を表示
$ kubectl rollout history deployment <handson-3>
$ kubectl rollout history deployment <handson-3> --revision=1
デプロイメントのロールバック（nginx:1.14に戻す）
$ kubectl rollout undo deployment <handson-3>
デプロイメントを削除
$ kubectl delete deploy/<handson-2>
サービスを削除
$ kubectl delete service <handson>
マニフェストを作成（デプロイメントとサービス）
vi manifest.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
creationTimestamp: null
labels:
run: handson-4
name: handson-4
spec:
selector:
matchLabels:
run: handson-4
template:
metadata:
labels:
run: handson-4
spec:
containers:
- image: nginx
name: handson-4
ports:
- containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
labels:
run: handson-4
name: handson-4
spec:
ports:
- port: 80
targetPort: 80
selector:
run: handson-4
type: LoadBalancer
マニフェストを適応（nginxとLBが作成される）
$ kubectl apply -f manifest.yaml
マニフェストで定義したオブジェクトを削除
$ kubectl delete -f manifest.yaml
Dockerfileの作成
$ vi Dockerfile
FROM google/cloud-sdk:latest
COPY . /app
RUN make app
CMD python /app/app.py
Dockerビルド
$ docker build -t myapp .
ビルドしたコンテナを起動
$ docker run -p 3000:3000 myapp
http://localhost:3000 へアクセスして確認
コンテナにタグ付け
$ docker tag myapp asia.gcr.io/${prjid}/myapp
GCRの認証
$ gcloud auth configure-docker
リポジトリへPush
$ docker push asia.gcr.io/${prjid}/myapp
デプロイ
$ kubectl run myapp --image=asia.gcr.io/${prjid}/myapp
$ kubectl expose deploy myapp --port=80 --target-port=3000 --type=LoadBalancer
ポッドを増やす
$ kubectl scale deployment myapp --replicas=3
確認
$ kubectl get all -l run=myapp
クラスタを削除
$ gcloud beta container clusters delete standard-cluster-1 --zone "asia-northeast1-a"
Dockerイメージの削除
$ gcloud container images list --repository asia.gcr.io/${prjid}
Dockerイメージの削除
$ gcloud container images delete asia.gcr.io/${prjid}/<myapp>
GKEのクラスターでConnect＞クレデンシャルcmdが分かる
gcloud contaier clusters get-credentials <clustername> --zone asia-northeast1-b --project unco
そのコマンドを承認済みNWの環境で実行する
kubectl get pods -n <namespace> | grep xxx
Podを特定したい、オプションnでネームスペース、-n無しだと現行のNS、--all-namespacesで全NS
kubectl exec -it <podname> -n <namespace> -- /bin/bash
これでPodに入れるので python xxx.py とかコマンド可能
さらにアクセスが必要なら
さらにアクセスが必要なら
kubectl config get-contexts
コンテキスト一覧（クラスタ、ユーザ、ネームスペースを組み合わせたもの）を表示
kubectl config use-context <コンテキスト名>
コンテキスト切り替え
kubectl port-forward service/<srv> 8080:80
ポートフォワード先を設定
別ターミナルを立ち上げ
curl "http://localhost:8080/api/v1/namespaces/<namespace>/pods/<pod>"
curl --silent 127.0.0.1:8080 | head -n 10
curl --silent 127.0.0.1:8080 | head -n 10
Kubernetes API RESTのサブリソース
サブリソースとは通常のリソースの HTTP パスに追加でサフィックスを付与した特別な HTTP パス
Service proxy: /api/v1/namespaces/<namespace>/services/<scheme>:<service>:<port>/proxy/
Pod のログを取得する: /api/v1/namespaces/<namespace>/pods/<pod>/logs
Pod のポートを転送する: /api/v1/namespaces/<namespace>/pods/<pod>/portforward
Pod で任意のコマンドを実行する: /api/v1/namespaces/<namespace>/pods/<pod>/exe
コンテナ起動時
• ステートレスな状態を維持する
• スケールアウト可能なアーキテクチャにする
• 設定は外部から注入できるようにする
• ログは標準出力に構造化ログで出力する
• いつでも容易に停止できるようにする
• SIGTERM シグナルをハンドリングする
• コンテナ上には単一プロセスのみ起動する
• ヘルスチェック用のエンドポイントを用意する
• アプリケーションの状態を可観測にする
• 起動時にアプリをダウンロードしない
ASM（anhtos service mesh)
サービスメッシュでマイクロサービス間で適切な通信する
マネージドな管理？監視/デプロイ/イングレスセキュリティ？コントロールプレーン？
DBやミドルウェアは外して別途管理が良いらしい
DBやミドルウェアは外して別途管理が良いらしい
全体の雰囲気
サイドカープロキシ
ASMがGKE本体に蜜結合することなくプロキシとして全てのトラフィックを傍受できる
周辺的なタスクをこなすという意味合いか
=========================
●DAGを使う
Kubernetes ネイティブなワークフローエンジン Argo Workflows | 豆蔵デベロッパーサイト (mamezou-tech.com)
Argo公式マニフェストが長すぎる？argo-helmでやるか
argo-helm/charts/argo-workflows at main · argoproj/argo-helm · GitHub
Quick Start - Argo Workflows - The workflow engine for Kubernetes (argoproj.github.io)
gcloud builds submit --pack image=gcr.io/bangboo-run/unco ならDockerfile不要らしい
