Blog

笠原桃奈ちゃんすき

Kubernetes 完全ガイド

読書メモ
 

第4章 APIリソースとkubectl

4.1 起動

  • gcloud init
  • gcloud container clusters create k8s --cluster-version 1.15.9-gke.26 --zone asia-northeast1-a --num-nodes 3
  • gcloud container clusters get-credentials k8s --zone asia-northeast1-a
  • kubectl create --save-config clusterrolebinding iam-cluster-admin-binding --clusterrole=cluster-admin --user=takedarut02@gmail.com

4.2 k8sの基礎

  • Node
    • Master
      • APIエンドポイントの影響
      • コンテナのスケジューリング
      • コンテナのスケーリング
    • Node
      • Dcokerホスト
  • 操作方法
    • 下記を用いる
    • これらをMaster nodeに対してリクエストを送付してk8sの操作を行う
      • RestAPIでできている
      • 直接呼び出してk8sを操作することも可能

4.3 k8sとリソース

  • k8sではリソースを登録することで、コンテナの実行やロードバランサの作成が非同期に行われる
  • リソースは多数あり、下記のAPIリファレンスで公開されている
  • リソースは下記の5種類が存在する
    • Workload
      • コンテナの実行に関わるリソース
    • Discovery & LB
      • コンテナを外部公開するようなエンドポイントを提供するリソース
    • Config & Storage
      • 設定・機密情報・永続化ボリュームなどに関するリソース
    • Cluster
      • セキュリティやクォータに関するリソース
    • Metadata
      • クラスタ内の他のリソースを操作するためのリソース
  • Workload
    • コンテナを起動するために利用するリソース
    • 下記の8種類のリソースが存在
      • Pod
      • ReplicationController
      • ReplicaSet
      • Deployment
      • DaemonSet
      • StatefulSet
      • Job
      • CronJob
  • Discovery & LB
    • エンドポイント提供のリソース
    • ServiceとIngressのに種類存在する
      • Service
        • ClusterIP
        • ExternalIP (One of ClusterIP)
        • NodePort
        • LoadBalancer
        • Headless (None)
        • ExternalName
        • None-Selector
      • Ingress
  • Config & Storage
    • 設定や機密データをコンテナに埋め込んだり、永続化ボリュームを提供するリソース
      • Secret
        • Key-Value
        • SecretとCoinfigMapは機密情報かどうかによって使い分ける
      • ConfigMap
      • PersistentVolumeClaim
        • コンテナから永続化ボリュームを要求する際に利用する
  • Cluster
    • クラスタ自体の振る舞いを定義する
      • Node
      • Namespace
      • PersistentVolume
      • ResourceQuota
      • ServiceAccount
      • Role
      • ClusterRole
      • RoleBinding
      • ClusterRoleBinding
      • NetworkPolicy
  • Metadata
    • クラスタ内のリソースを制御するためのリソース
      • LimitRange
      • HorizontalPodAutoscaler
      • PodDisruptionBudget
      • CustomResourceDefinition

4.4 Namespaceによる仮想的なクラスタの分離

  • Namespace
    • 仮想的なKubernetesクラスタの分離機能
    • 完全な分離ではない
    • 複数チームで利用
    • Production/Staging/developmentなどのように環境ごとに分割可能
  • kube-system
  • kube-public
    • 全ユーザーが利用できるConfigMapなどを配置
    • パブリックユーザー
  • default
    • デフォルトのNamespace
    • ユーザーが任意のリソースを利用できる
  • マネージド・サービスで構築されるNameSpaceのほとんどがRBAC (Role-based Accesss Control)になっている
    • クラスタに関する権限をNamespaceに対して分けることができる
    • Network Policyと組み合わせることでNamespace間通信の制御が行える仕組み
    • Namespaceだけではそこまでの分離性はないがこれらを利用して分離性を高める

4.5 CLIツールkubectl

  • kubectlがMasterと通信するには認証情報が必要
  • kubeconfigに記載されている情報で接続を実施する
    • cluster/users/contextsで設定する
      • cluster: 接続先のクラスタ情報
      • users: 認証情報
      • contexts: cluster, user, namaspaceの指定を行う
  • kubeconfigは直接編集も可能だが、kubectlコマンドで編集することも可能
  • 操作
    • clusterの作成
    • ユーザーの定義
      • kubectl config set-credentials admin-user --client-certificate=./sample.crt --client-key=./sample.key --embed-certs=true
    • Contextの定義
      • kubectl config set-credentials admin-user --client-certificate=./sample.crt --client-key=./sample.key --embed-certs=true
    • 現在のContextの表示
      • kubectl config set-context prd-admin --cluster=prd-cluster --user=admin-user --namespace=defalut
  • これらが冗長に感じる場合はkubectxやkubensを利用しても良い
  • マニフェストとリソースの作成・削除・更新
    • 一つのコンテナからなるPodを作成する
      • Podって
        • https://kubernetes.io/ja/docs/tutorials/kubernetes-basics/explore/explore-intro/
        • Podには下記が含まれる
          • 共有ストレージ
          • ネットワーキング
          • コンテナのイメージバージョンや使用するポートなどの各コンテナをどのように動作させるかに関する情報
        • APサーバーとWebサーバーを含めることができる
        • pod内のコンテナはipアドレスとポートスペースを共有し、常に同じ場所に配置され、同じスケジュールに入れられ、同じノード上の共有コンテキストで実行できる
        • 最小単位
        • k8sにdeploymentを作成するとその中にコンテナを持つpodを作成します
        • 各podはスケジュールされているノードに関連付けられている。終了または削除されるまでそこに残る
        • ノードに障害が発生した場合同じpodがクラスター内の利用可能なノードにスケジュールされる
      • ノードって
        • Podはノード上で常に動作する
        • ノードはk8sのワーカーマシン
        • クラスタで仮想物理マシンでもよい
        • マスターはクラスター内のノード間でPodのスケジュールを自動的に処理する
          • マスターもノードの一種
          • マスター＋ノードでクラスタ
    • podの作成
      • kubectl create -f sample-pod.yaml
    • podの削除
      • 通常終了
        • kubectl delete -f sample-pod.yaml
      • 強制終了
        • kubectl delete -f sample-pod.yaml --grace-period 0 --force
    • podの更新
      • kubectl apply -f sample-pod.yaml
      • yamlをupdate後に更新コマンドの実行
    • podの確認
      • バージョン確認
        • kubectl get pods sample-pod -o jsonpath={.spec.containers[].image}
      • 単純な稼働確認
        • kubectl get pods sample-pod

4.5.4 リソース作成にもkubectl applyを使うべき理由

  • kubectl applyで適用される差分
  • 今回追加/更新されるマニフェスト項目
  • 今回削除されるマニフェスト項目
  • 現在と前回って何が違うの？
    • 現在はシステムコンソールでいじることができる。
    • すなわち前回のコンフィグと同じ状態になっているとは限らない
    • そのため削除項目に関しては前回のマニフェストと比較を実施する
    • kubectl createは前回の状態が保存されない
    • 今回適用するマニフェストとの差分がわからなくなる、特定の設定値を削除できない場合は生じうるのでkubectl applyを利用するべき

4.5.5 マニフェストファイルの設計

4.5.6 アノテーションとラベル

  • アノテーション
    • metadat.annnotations
    • メモ書きのようなもの
    • 下記の3つの用途で利用される
      • システムコンポーネントのためにデータを保存する
      • すべての環境では利用できない設定を行う
      • 正式に組みこまれる前の機能の設定を行う
    • システムコンポーネントのためにデータを保存する
    • すべての環境では利用できない設定を行う
      • GKE、EKSはローカルIPアドレスを用いたインターナルエンドポイントの作成も可能
      • これらは特定のアノテーションを付与することで実現する
      • すべてのk8sで利用できないものに関してはアノテーションで制御できるようにしている
  • 正式に組み込まれる前の機能の設定を行う
  • ラベル
    • metadata.labels
    • リソースをぶっb熱するため
    • 多くのリソースを同一ラベルでグルーピングして処理したり、条件分に利用したりする
    • 下記の二週類ある
      • 開発者が利用するラベル
      • システムが利用するラベル
    • 開発者が利用するラベル
      • kubectlを用いて対象のリソースのみを操作することができる
      • -l -Lオプションとかあるよ
    • システムが利用するラベル
      • ラベル名は衝突する可能性あり
      • たとえばreplicas=3で起動しているPodに同じラベルでPod新たに起動すると既存のPodに影響がある可能性があります
      • LBも特定のラベルのものに流すとかが可能なので、よきせぬ自体が発生しうる
    • ラベルは
      • プロジェクト
      • アプリケーションの種類
      • アプリケーションのバージョン
      • 環境

4.5.7 Pruneによるリソースの削除

  • 手動でkubectlを実運用でするこてゃない
  • Git で管理しておいて、applyする方式が良い
  • --pruneでリソースの削除が可能
  • マニフェストファイル自体を削除しても、マニフェストファイル内の特定のリソースを削除しても反映される
  • Pruneの挙動
    • マニフェストファイルの削除された項目を削除しているように見えるが違う
    • ラベルに一致するすべてのものから削除されたものを削除している
    • したがってラベル指定が必須
    • --allオプション
      • マニフェストに読ませなかったリソース以外をすべて削除対象となる
      • 危険
    • ラベル設計はとても大事

4.5.8 エディタによる編集

  • kubectl edit
  • vi
  • export EDITOR=vim
  • kubectl edit pod sample-pod

4.5.9 リソースの一部情報の更新

  • kubectl set
  • これを用いて一部設定値のみ動作状態を変更することができる
    • env
    • image
    • resources
    • selector
    • serviceaccount
    • subject
  • kubectl describe pod sample-pod
    • コンテナイメージの確認
  • kubectl set iamge pod sample-pod nginx-container=nginx:1.12

4.5.10 リソースの情報取得（get）

  • kubectl get
  • これでリソースの一覧を取得できる
  • -l -L でラベル取得
  • -o で形式を指定もできる
  • Go Template

4.5.11 リソースの詳細情報の取得（describe）

  • リソースの詳細な情報を知りたい場合はkubectl describeを利用する

4.5.12 実際のリソースの利用料の確認（top）

  • Pod内のコンテナが利用しているリソースの使用量は kubectl top で確認可能

4.5.13 Pod上でのコマンドの実行（exec）

  • Pod上で特定のコマンドを実行したい場合は kubectl exec コマンドを利用しましょう
  • /bin/sh を利用すればコマンド実施可能
  • Pod内のコンテナ
    • kubectl exec -it sample-pod /bin/sh
  • 複数コンテナ履いたPod内で特定コンテナ
    • kubectl exec -it sample-pod -c nginx-container /bin/sh

4.5.14 Podのログ確認（log）

  • kubectl logs を利用する
  • kubectl logs sample-pod
  • kubectl logs sample-pod -c nginx-container
  • lubectl logs -f sample-pod
  • kubectl logs --sice=1h --tail=10 --timestamp=true sample-pod

4.5.15 Sternによる高度なログ確認

  • Sternを利用することで高度なログ出力が可能
  • 複数のコンソールを見る必要があるのがデフォルトだが、１つのコンソールで完結できるようになる

4.5.16 コンテナとローカルマシンの間でのファイルコピー（cp）

  • kubectl cp

4.5.17 ローカルマシンからPodへのポートフォワーディング（port-forward）

  • kubectl port-forward
  • これを実行時には複数のPodに対して分散して送信しているわけでなく、実行時にしていたものに配信される
  • ローカルホストの特定の通信を特定のPodに送信するようにする

4.5.18 kubectlの補完機能（completion）

4.5.19 kubectlにおけるデバッグ

  • -v でログレベルを指定することでできる
  • -v=6: HTTP通信概要
  • -v=8: 詳細まで

4.5.20 kubectlのその他のTIPS

  • alliasaの作成
  • kube-ps
  • Podが起動しないときのデバッグ
    • kubectl logs
    • kubectl describe
    • kubectl run
      • 実際のコンテナでの動作を確認してしまう

第5章 Workload リソース

5.1 Workloads リソースの概要

  • Podを最小単位として管理する上位リソースがある構造
  • Pod
    • ReplicationController
    • ReplicaSet
      • Deployment
    • DaemonSet
    • StatefulSet
    • job
      • CronJob

5.2 Pod

  • gggg1つ以上のコンテナで構成されている
  • PodごとにIPアドレスが割り当てられる
  • Pod内のコンテナはお互いにLocalhostで通信可能
  • 多くの場合は1pod 1container
  • サブコンテナの例
    • Proxy
    • 設定値の更新用
    • ローカルキャッシュ
    • SSL終端用
  • Podのデザインパターン
    • サイドカー
      • メインコンテナに機能を追加
    • アンバサダー
      • 外部システムとのやり取りの代理
    • アダプタ
    • サイドカー
      • 例
        • 特定の変更検知下さいに動的に設定を変更するコンテナ
        • Gitリポジトリとローカルストレージを動悸する
        • アプリケーションのログファイルをオブジェクトストレージに転送するコンテナ
    • アンバサダー
      • ShardingされたDBやRedisなどに接続する際に結合度を下げるために、Proxy経由でアクセスをする
      • その結果Applicationはlocalhost経由でDBアクセスをするようになり、いい感じに疎結合になる
    • アダプター
      • 差分吸収
      • Prometheusなどのソフトウェアにあった決まったフォーマットでメトリクス収集を行う
      • その際の変換用のコンテナを内包する
  • Podの作成
    • 複数のPodを起動することが可能
    • Podないでポートかぶりが発生すると起動に失敗する
    • マニフェストファイルの先に記述があるものが起動する
  • コンテナへのログインとコマンドの実行
    • 擬似端末を生成-t, 標準入力をパススルー -i
    • コンテナないへ入る
      • kubectl exec -it sample-pod /bin/bash
    • コマンド実行
      • kubectl exec -it sample-pod ls
    • 特定コンテナを指定
      • kubectl exec -it sample-2pod -c nginx-container ls
    • オプション含むコマンド実行
      • kubectl exec -it sample-pod -- ls --all --classify
    • パイプを含むとき
      • kubectl exec -it sample-pod -- sh -c "ls --all --classify | grep media"
  • ENTRYPOINT/CMDとcommand/arfs
    • ENTRYPOINT → command
    • CMD → args
  • コンテナ内でのプロセスとかのインストール
    • apt update && apt -y install iproute procps
  • Pod名の制限
    • Pod名に制限あり
    • RFC1123に従う必要あり
      • 利用可能な文字は英小文字と数字
      • 利用可能な記号は-.
      • 始まりと終わりは英小文字
    • アンダーバーはだめよ
  • PodのDNS設定（dnsPolicy）とサービスディスカバリ
  • 静的な名前解決の設定

5.3 ReplicaSet/ReplicationController

  • Podのレプリカを作成して、その数のPodを維持し続けるリソース
  • ReplicationControllerは廃止の方向なので、ReplicaSetを利用するようにしましょう
  • ReplicaSetの作成
  • Podの停止とセルフヒーリング
k8s ryotaro$ kubectl get pods -o wide
NAME              READY   STATUS    RESTARTS   AGE     IP         NODE                                 NOMINATED NODE   READINESS GATES
sample-rs-p7wsz   1/1     Running   0          7m45s   10.8.2.8   gke-k8s-default-pool-9a16beca-xvmz   <none>           <none>
sample-rs-sgtw5   1/1     Running   0          7m45s   10.8.1.6   gke-k8s-default-pool-9a16beca-dtgp   <none>           <none>
sample-rs-zh6z9   1/1     Running   0          7m45s   10.8.2.9   gke-k8s-default-pool-9a16beca-xvmz   <none>           <none>
k8s ryotaro$ kubectl delete pod sample-rs-p7wsz 
pod "sample-rs-p7wsz" deleted
k8s ryotaro$ 
k8s ryotaro$ 
k8s ryotaro$ kubectl delete pod sample-rs-p7wsz 
Error from server (NotFound): pods "sample-rs-p7wsz" not found
k8s ryotaro$ kubectl get pods -o wide
NAME              READY   STATUS    RESTARTS   AGE     IP          NODE                                 NOMINATED NODE   READINESS GATES
sample-rs-rn7qw   1/1     Running   0          13s     10.8.0.11   gke-k8s-default-pool-9a16beca-nb6g   <none>           <none>
sample-rs-sgtw5   1/1     Running   0          8m12s   10.8.1.6    gke-k8s-default-pool-9a16beca-dtgp   <none>           <none>
sample-rs-zh6z9   1/1     Running   0          8m12s   10.8.2.9    gke-k8s-default-pool-9a16beca-xvmz   <none>           <none>
    • kubectl describe rs でpodの増減を確認可能
  • ReplicaSetとラベル
    • spec.selector.matchLabels で一致したラベルに対してReplicationを実施する
    • selectorで指定したラベルがtemplateにいない場合はエラーとなる
    • 追加した場合もどれかが死ぬ
  • ReplicaSetのスケーリング
    • スケールする方法は
      • マニフェストを書き換えて、 kubectl appluy -f する
        • sed -e 's/replicas: 3/replicas: 5/' sample-rs.yaml | kubectl apply -f -
        • Infrastructure as a code
      • kubectl scale コマンドを利用する
        • kubectl scale rs sample-rs --replicas 10
  • equality-based条件とset-based条件
    • set-basedを使おう
    • = とか in [aaa, bbb]などで記述する
    • 後日

5.4 Deployment

  • Deployment は ReplicaSet を管理することで、ローリングアップデートやロールバックを実現するリソース。
  • Deployment → ReplicaSet → Pod という3層構造
  • 基本的には下記のフロー
    • 新しいReplicaSetを作成
    • 新しいReplicaSet上のレプリカ数を徐々に増やす
    • 古いReplicaSet上のレプリカ数を徐々にへらす
    • くりかえす
    • 古いReplicaSetはレプリカ数0で維持する
  • Deploymentを利用するとこんな良いことが！
    • 新しいReplicaSetでコンテナが起動したことやヘルスチェックが通っていることを確認しながら切り替えを行ってくれる
    • 移行過程におけるPodの細かい指定も可能
    • Kubernetesにおける最も推奨されているコンテナの起動方法です
    • 単体コンテナでもDeploymentを利用するべき
    • 自動再生やローリングアップデートできません
  • Deployment の作成
    • 履歴を残しながら
      • kubectl apply -f sample-deployment.yaml --record
    • アップデート
      • kubectl set image deployment sample-deployment nginx-container=nginx:1.13
    • ロールアウト状況の確認
      • kubectl rollout status deployment sample-deployment
  • Deployment のアップデート（ReplicaSetが作成される）
    • Deploymentでは変更があるとReplicaSetされると説明しました
    • 作成されるPodの内容の変更が必要。
    • spec.templateに変更がある = 作成されるPodの変更
    • spec.template配下の構造体を用いたハッシュ値でラベル化している。そのため、戻して同じ構造にした場合はハッシュ値が一致するために、既存のReplicaSetを利用する
  • 変更のロールバック
    • Deploymentが作成したReplicaSetは基本的に履歴としてレプリカ0で形だけは残っているのでレプリカ数を増やすことで再度利用が可能
    • 変更履歴の確認方法
      • kubectl rollout history deployment sample-deployment
      • CHANGE-CAUSE
        • --recordオプションを用いたなかった場合は空になります
    • 該当リビジョンの詳細情報取得
      • kubectl rollout history deployment sample-deployment --revision 1
    • リビジョンを指定してロールバックする場合
      • kubectl rollout undo deployment sample-deployment --to-revision 1
    • 1つ前にロールバックする場合
      • kubectl rollout undo deployment sample-deployment
    • 実際はあんま使わない
    • Deplyment更新の一時停止
      • 更新を適用しても待ってほしいケースに対応するために、、、
      • 一時停止
        • kubectl rollout pause deployment sample-deployment
      • 一時停止解除
        • kubectl rollout resume deployment sample-deployment
      • この状況ではアップデートは待機状態のまま
      • ロールバックもできない
    • rolling-updateコマンド
      • 非推奨
    • Deploymentのアップデート戦略
      • Deploymentをアップデートするとローリングアップデートが実行された。
      • これはspec.strategy.typeがRoliingUpdateになっているため
      • アップデート戦略には下記の2種類の戦略がある
        • Recreate
        • RollingUpdate
      • Recreate
        • 一度すべてのPodを削除してから再度作成するので、ダウンタイムが入るが切り替えが早かったり、余剰なリソースを利用しない
      • RollingUpdate
        • 下記を設定可能
          • 許容される扶翼Pod数 : maxUnavailable
          • 超過Pod数: maxSurge
        • 個数でもパーセンテージでも指定可能
    • より詳細なアップデートパラメータ
      • minReadySeconds
        • PodがRedyになってからDeploymentリソース的にPod起動が完了したとみなすまでの最低秒数
        • 長くすれば待つのかな？
      • revisionHistoryLimit
      • progressDeadlineSeconds
    • Deploymentのスケーリング
      • kubectl scale or kubectl apply -f
    • マニフェストを書かずにDeploymentを作成する
      • kubectl run コマンドを利用することで、マニフェストを書かずにDeploymentを作成可能

5.5 DaemonSet

  • DaemonSetはReplicaSetの特殊な形とも言えるリソース
  • ReplicaSetは各Kubernetes Node上に合計でN個のPodをNodeのリソース状況に合わせて配置していく
  • DaemonSetは各ノードにPodを一つづつ配置するリリース
  • Podを配置したくない場合はにはそのようにすることができる
  • ユースケース
    • 各Podが出力するログをホスト単位で週憂愁するFluentdやDatadogなど各Nodeに必ず動作したいプロセスを利用することが多い
  • DaemonSetの作成
  • DaemonSetのアップデート戦略
    • アップデート戦略を選択することが可能
      • RollingUpdate
        • 随時Update
      • OnDelete
        • マニフェスト変更時にPodの更新をせず、別の要因でPodが更新されるときに新しい定義でPodを更新する
    • OnDelete
    • RollingUpdate

5.6 StatefulSet

  • こいつもReplicaSetの特殊系といえるリソース
  • データベースなどステートフルなワークロードに対応するためのリソース
  • ReplicaSetとの違いは
    • 作成されるPod名のサフィックスは数うじのインデックスが付与されたものになる
    • データを永続化するための仕組みを有している
      • persistentVolumeを使っている場合はPodの再起動時に同じディスクを利用して再作成される
      • Pod名が変わらない
  • StatefulSetの作成
    • PersistenVolumeClaimを設定することが可能
    • これを設定sることでクラスタ外のネットワークごしに提供されるPersistentVolumeにPodをアタッチすることができる
    • Pod再作成後も同じデータを保持した状態でコンテナが再作成されるようになる
    • https://github.com/Rtaro02/studyk8s/blob/master/sample-statefulset.yaml
    • ボリューム状態の要求
      • kubectl get persistentvolumeclaims
    • ボリュームの状態
      • kubectl get persistentvolumes
  • StatefulSetのスケーリング
    • kubectl scale
    • kubectl apply -f
    • レプリカ数の変更によるPodの作成・削除が発生した場合には1こずつ作成・削除するため時間がかかる
    • 並行でPodを作成しない
    • インデックスが多いものから作成され、削除されていく
      • ReplicaSetの場合はランダムに削除される
      • 特定のPodがマスターの場合はReplicaSetは向かない
      • StatefulSetの場合はindexが0のものは最初に作成・最後に削除なので向いている
  • StatefulSetのライフサイクル
  • StatefulStateのアップデート戦略
    • 下記2つ
      • RollingUpdate
      • OnDelete
    • OnDelete
      • DaemonSetと同様
    • RollingUpdate
      • StatefulSetでは永続化データがあるため、余分なPodを残してのローリングアップデートはできない
      • 一度に停止可能なPod数(maxUnavailable) を指定してからのローリングアップデートもできない、1つのPodずつアップデートを行います
      • partitionというパラメータを設定可能
        • 設定した値以下のインデックスのPodは更新されない。
        • 他のものはアップデートしまくります
        • spec.updateStrategy.rollingUpdate.partition で指定
  • 永続化領域のデータ保持の確認
    • Podを削除しても、プロレスをkillしても永続化データは保持されたまま
  • StatefulSetの削除とPersistentVolumeの削除
    • StatefulSetを削除してもPersistentVolumeは残ったまま
    • 再起動してもアクセス可能
    • 永続化領域を開放しよう
    •  kubectl delete persistentvolumeclaims www-sample-statefulset-{0..4}

5.7 Job

  • コンテナを利用して一度限りの処理を実行するリソース
  • N並列で実行しながら、指定した回数のコンテナの実行を保証するリソース
    • 3並列で5回実行が成功するまでPodを起動する例
  • ReplicaSetとの違いとJob使い所
    • ReplicaSetとの大きな違いは「起動するPodが停止することを前提にして作られているか」
    • Podの停止が正常終了となるような用途にむいている
      • 特定のさーばとのrsync
      • S3などのObject Storageへのアップロード
    • バッチ的な処理にはJobを積極的に利用しましょう
  • Jobの作成
  • restartPolicyによる挙動の違い
  • 並列Jobとワークキュー型の実行
    • 下記2点を設定していた
      • 成功回数
        • completions
      • 並列度
        • parallelism
      • これらはデフォルト値は1
    • completions/parallelism/backofflimitは非常に重要なパラメター
    • 下表の設定例、N,M,Pは任意の数
ワークロード
completion
成功数
parallelism
並行数
backoffLimit
終了判定失敗数
一回だけ実行するタスク
1
1
1
N並列で実行するタスク
M
N
P
1個ずつ実行するワークキュー
未指定
1
P
N並列で実行するワークキュー
未指定
N
P

5.8 CronJob

  • Jobに似たリソースとしてCronJobが存在する。
  • Jobの亜種に見言えるが、CronJobはJobと親子関係にある
    • CronJobがJobを管理し、JobがPodを管理するような体型になっている
  • Cronjobの一時停止
    • kubectl patch cronjob sample-cronjob -p '{"spec":{"suspend":true}}'
  • 同時実行に関する制御
    • 正常終了している限りは明示的に指定しなくても同時実行されることな新たなJobが作成される
    • 古いJobがまだ実行中の場合はポリシーで新たなJobを実行するかどうかの制御を行いたいケースがあります
    • このポリシーは spec.concurrencyPolicy で指定します
      • Allow
        • 同時実行忍耐して制御を行わない
      • Forbit
        • 前のJobが終了していない場合は、次のJobは実行しない
      • Replace
        • 前のジョブをキャンセルし、Jobを開始する
    • 実行開始期限に関する制御
      • 指定した時刻になるとKubernetes MasterがJobを作成する
        • この際にMasterがダウンしていた場合など、開始が遅れたときに許容できる秒数 (spec.startingDeadlineSeconds) を指定することができる
        • デフォルトではどんだけ遅れてもJobを開始するようになっている
    • Cronobの履歴
      • 保存していくJobの数を指定する
        • spec.successfulJobsHistoryLimit
          • 成功したJobを保存する数
        • spec.failedJobsHistoryLimit
          • 失敗したJobを保存する数
      • Jobが残っている = 紐づくPodも残っている

第6章 Discovery & LB リソース

6.1 Discovery & LBリソースの概要

  • Discovery & LBリソースには
    • クラスタ上のコンテナに対するエンドポイントの提供
    • ラベルに一致するコンテナのディスカバリに利用されるリソース
  • 2種類のリソースが存在する
    • L4ロードバランシングを提供するServiceリソース
    • L7ロードバランシングを提供するIngressリソース
  • Service
    • ClusterIP
    • ExternalIP
    • NodePort
    • LoadBalancer
    • Headless
    • ExternalName
    • None-Selector
  • Ingress

6.2 KubernetesクラスタのネットワークとService

  • Pod内には複数のコンテナがあるが、すべて同じIPアドレスが割り当てられている
  • 同じPod内であればlocalhost, 他のPodからであればIPアドレスを指定する
  • クラスタを構成するとノードにPodのための内部ネットワークを構成する
    • CNI（Container network）というモジュールの実装次第
    • ノード間のトラフィックがお互いが通信ができるように構成する
    • これらの内部ネットワークが自動構成をするためにPodはServiceを利用せずともPod間の通信を行うことが可能
    • しかしServiceのを利用することによるメリットは下記
    • これらの機能はどのService typeからも利用できる
  • Pod内のトラフィックのロードバランシング
    • Serviceは受信したトラフィックをPodにロードバランシングする機能を提供する
    • Serviceはロードバランシングの接続ぐちとなるエンドポイントを提供する
    • ClusterIPでは、ラベルで指定したアプリケーションに対してロードバランシングをする
  • クラスタ内DNSとサービスディスカバリ
    • サービスディスカバリってなんぞや
      • 特定の条件の対象となるメンバを列挙する
      • 名前からエンドポイントを判別する機能
    • サービスディスカバリの方法
      • 環境変数を利用したサービスディスカバリ
      • DNS Aレコードを利用したサービスディスカバリ
      • DNS SRVレコードを利用したサービスディスカバリ
    • 環境変数を利用したサービスディスカバリ
    • DNS Aレコードを用いたサービスディスカバリ
      • 他のPodからServiceで払い出されるエンドポイントへの接続するにはIP以外にもDNSレコードを利用することもできる。これを使うのが好ましい。
      • ClusterIP Serviceのメタデータに指定した名前でアクセス可能
        • FQDNはService名.Namespace.snv.cluster.local
        • Namespaceを名をつけて名前解決を行うがよさそう
      • 下記で検索は可能
        • kubectl run --image=centos:6 --restart=Never --rm -i testpod -- cat /etc/resolv.conf
      • 逆引きも可能
        • kubectl run --image=centos:6 --restart=Never --rm -i testpod -- dig -x 10.11.240.10
    • DNS SRV レコードを用いたサービスディスカバリ
      • ServiceのPort名.Protocol.ServiceName.Namespace.svc.cluster.local
      • SRVを解釈できる場合はこのようにサービスを提供しているPort番号を含めたエンドポイントまでDNSを解決することが可
    • クラスタ内DNSとクラスタ外DNS

6.3 ClusterIP Service

  • クラスタ内ロードバランシングとしてはClusterIP Serviceが利用される
  • 何も設定していないとkubernetes serviceが作成されている
  • ClusterIP Serviceの作成
    • type: ClusterIP
    • 受け取りもと: spec.ports.port
    • てんそうさき: spec.ports.targetPort
  • ClusterIP 仮想IPの静的指定
    • 手動設定を利用する場合にはspec.clusterIPを利用する
    • kubectl applyでもclusterIPは設定変更できないimmutableな値
      • takedarut@RYOTARO-THINKPAD:~/repositories/k8s$ kubectl apply -f sample-clusterip-vip.yaml
      • The Service "sample-clusterip-vip" is invalid: spec.clusterIP: Invalid value: "10.11.253.83": field is immutable

6.4 ExternalIP Service

  • ExternalIP Service
    • 特定のKubernetes NodeのIPアドレス:Portで受信したトラフィックをコンテナに転送する形で外部疎通性を確立するService
    • ExternalIP Serviceの作成
      • typeはClusterIP
      • 設定するIPたち
        • spec.externalIP: Kubernetes NodeのIPアドレス
        • spec.ports.port: ExternalIP, ClusterIPで受け取るPort番号
        • spec.ports.targetPort: 転送先のコンテナのPort番号
      • ExternalIPに利用可能なIPアドレスはノード情報から確認することが可能
      • GKEの場合はGCEに割り当てられたOSから確認できるInternal IPのみ当てられる
      • ノードに直接グローバルIPがあられている場合は
        • kubectl get nodes -o custom-columns="NAME:{metadata.name},IP:{status.addresses[].address}"
      • ExternalIPを指定しないとしてい無しのときの外部IPあり版？
      • クラスタ内DNSがかえすIPはClusterIP
takedarut@RYOTARO-THINKPAD:~/repositories/k8s$ !366
kubectl run --image=centos:6 --restart=Never --rm -i testpod -- dig sample-externalip.default.svc.cluster.local
 
; <<>> DiG 9.8.2rc1-RedHat-9.8.2-0.68.rc1.el6_10.1 <<>> sample-externalip.default.svc.cluster.local
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1333
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
 
;; QUESTION SECTION:
;sample-externalip.default.svc.cluster.local. IN        A
 
;; ANSWER SECTION:
sample-externalip.default.svc.cluster.local. 30 IN A 10.11.249.88
 
;; Query time: 2 msec
;; SERVER: 10.11.240.10#53(10.11.240.10)
;; WHEN: Wed Apr 15 13:07:55 2020
;; MSG SIZE  rcvd: 77
 
pod "testpod" deleted
takedarut@RYOTARO-THINKPAD:~/repositories/k8s$ kubectl get services
NAME                TYPE        CLUSTER-IP     EXTERNAL-IP             PORT(S)    AGE
kubernetes          ClusterIP   10.11.240.1    <none>                  443/TCP    4m11s
sample-clusterip    ClusterIP   10.11.246.59   <none>                  8080/TCP   102s
sample-externalip   ClusterIP   10.11.249.88   10.240.0.7,10.240.0.8   8080/TCP   2m35s

6.5 NodePort Service

  • ExternalIPに近いサービス
  • すべてのノードに対してListenするようなサービス。ExternalIPは設定したノードのみListenしていた。
  • spec.ports.nodePortに全K8sで受けるPortを指定する。全k8s上でバッティングしないようなPort選びが必要
    • 指定しないと空いている番号があたる
  • 30000 - 32767のポート範囲を指定しないとNG
  • ノード間通信の排除
    • 複数nodeある場合は、NodeのIP指定してもかってに別のNodeのPodにロードバランシングされてしまう
    • もし、特定のNodeのPodのみに通信したい場合は下記の設定を利用する
      • spec.externalTrafficPolicy
        • Cluster: 全部のPodにロードバランシングする。全Nodeに均等、、、というわけではなく自分のNodeへのリクエストが多くなる傾向にある模様
        • Local: 指定したNodeのPodのみにロードバランシングする。Node内にPodが複数ある場合は均等にロードバランシングする

6.6 Load Balancer Service

  • NodePortやExternalPortは結局NodeのIPを指定するので、そのIPがSPOFになりかねない。
  • Load Balancer Serviceはそんなことは起きない。なぜなら外部にLBを建てるので。
  • Nodeに障害が発生した場合には、そのNodeに対してトラフィックを転送しないようにする。自動的に復旧する要になっている。一定時間の通信断は発生する可能性あり。
  • LoadBalancer Serviceの作成
    • spec.ports.ports: LoadBalancerが払い出す仮想IPとClusterIPで受けるport
    • spec.ports.targerPort: 転送先コンテナのport
    • spec.ports.nodePort: 全k8s nodeのIPで受け付けるport番号
  • ノード間通信の排除
    • ノード上に対象のPodがない場合は通信できなくなってしまうので利用しないほうがベター
    • externalTrafficPolicyで指定
  • 静的IPの指定
    • LoadBalancerが払い出す仮想IPの指定
      • spec.loadBalancerIPで指定
      • GCPの場合は静的アドレスをダッシュボードから予約して指定する
  • ファイアーウォールの設定
    • LoadBalancerサービスはFirewallを指定することで実行可能
    • 未指定の場合は全世界に公開される
    • 場合によってはk8s側でアクセス制御が実装されていない。その場合はNetworkPolicyリソースの利用も検討が必要かも
    • GKEではtype: LoadBalancerを利用すると、GCLBが作成される。これ削除しないでGKEクラスタを消してもLBは残り続けるので注意。ちゃんと削除しような！

6.7 Headless Service (None)

  • Headless Serviceは対象のPodのIPアドレスが直接帰ってくるService
  • DNS Round robin でPodのIPが直接帰ってくっる
  • StatefulSetの場合のみPod名も名前解決可能
  • Headless Serviceの作成
    • 利用には下記の3条件を満たす必要がある
      • Serviceがspec.typeがClusterIP
      • Serviceのspec.clusterIPがNoneであること
      • Serviceのmetadata.nameがStatefulSetのspec.serviceNameと同じであること
    • 3爪の条件が満たされていいない場合には、DNS RRでディスカバリするHeadless Serviceとしてしか動作せず、Pod名を引くことができない

6.8 ExternalName Service

  • Service名の名前解決に対して任意の外部のCNAMEを返却することができる
  • 利用場面は別の名前を設定しない場合や、クラスタのエンドポイントを切り替えやすくするため
  • アプリケーションに外部アプリケーション名を書き込んでしまうとその書換が発生してしまう。デプロイし直しが発生する。そのため、ExternalNameを利用すると、アクセス先の切り替えをExternalName Serviceの切り替えを行うだけで可能になる
  • ServiceのFQDNを指定することでExternalNameのCNAMEレコードか、ClusterIPのAレコードが変えるようになる
    • ClusterIPからExternalNameに変更する場合は、spec.clusterIPを明示的に殻にしないとだめ
      • spec.clusterIP: ““
      • 明示的とは↑

6.9 None-Selector Service

  • 自分で指定したメンバに対してロードバランシングする
  • None-Selector ServiceではClusterIPのAレコードがかえる
  • アプリケーションからは同じClusterIPとして見せることができる
  • None-Selector Serviceの作成

6.10 Ingress

  • L7ロードバランシングを提供するサービス
  • kind: Ingressタイプのリソースをつかう
  • リソースとコントローラ
    • リソースをk8sに登録するところから処理が始まるが、コントローラーが実際の処理を実行する
  • Ingressリソースとコントローラ
  • Ingressの種類
  • クラスタ外のロードバランシング
    • Ingressリソースを作成するだけでLBの仮想IPが払い出される
    • クライアント → L7 → Pod
  • クラスタ内にIngress用のPodをデプロイするIngress
    • 内部にPodを作成する必要がある
    • Ingress用のPod宛にLoadBalancer Serviceを作成するなどの準備が必要
    • クライアント → L4 → Nginx → Pod
  • Ingressを利用する前の事前準備
    • 事前にServiceを作成する必要あり
    • Nordport経由の転送だったりするので
    • InrgessでHTTPSを利用する場合には事前に証明書をSecretリソースとして作成しておく必要がある

第7章 Config&Storage リソース

7.1 Config&Storage リソースの概要

  • 下記3種類のリソース
    • Secret
    • ConfigMap
    • PersistentVolumeClaim

7.2 環境変数の利用

  • Kubernetesでは個別のコンテナに対する設定は環境変数やだファイルが置かれた領域にマウントしてわたすことが一般的
  • Kubernetesに環境変数を渡す場合には、Podテンプレートにenv, envFromを指定する。下記の5種類の情報源から環境偏するを埋め込むことが可能
    • 静的設定
    • Podの情報
    • コンテナの情報
    • Secretリソースの機密情報
    • ConfigMapリソースの設定値
  • 静的設定
    • spec.container.envに設定
  • Podの情報
    • どのノードで起動しているか、Pod自身のIPアドレス、起動時間などのPod情報はfieldRefで参照可能
    • 参照可能な値に関しては kubectl get pods -o yaml で確認可能
  • コンテナの情報
    • resourceFieldRefを使うことで参照することが可能
    • 参照可能な値に関しては kubectl get pods -o yaml で確認可能
    • spec.containers.name.env.valueFrom.resourceFieldRef
  • Secretリソースの機密情報
    • Secretリソースを利用する
  • ConfigMapリソースの設定値
    • 単純なKey-Value値や設定ファイルは ConfigMapで管理することが可能
    • 複数Podに重複がある場合に一括変換できるとかやりやすい
    • ConfigMapリソースで紹介
  • 環境変数利用時の注意点
    • 起動時の引き数に${}ではなく、$()を利用する
    • argsで参照可能なのはマニフェストファイル内のもののみもののみ
    • Entrypoint spec.containers.command をシェルスクリプトにして、シェルスクリプト内で処理をすることで変数を取得可能

7.3 Secret

  • ユーザー名やパスワードのような機密情報はどのようにコンテナに渡すのか？
    • Dockerビルド時にコンテナイメージに埋め込んでおく
      • コンテナイメージに書き込むことは可能だが、レジストリに機密情報が保存される、変更があるとイメージビルドをする必要があるなど結構たいへんです
    • PodやDeploymentのマニフェストに記載して渡す
      • マニフェストに機密情報が入ってしまうので管理が困難
      • 機密情報は別リソースに管理しておき、Podに読み込む。それがSecretリソース
      • Secretのマニフェストはbase64でエンコードされているが、暗号化されているわけではない。
      • Secretが定義されたマニフェスト暗号化するkubesecなどがある
  • Secretの分類
  • GenericタイプのSecret
    • スキーマレスの Secretを作る場合はタイプをgenericにする
    • 作成方法は4パターン
      • kubectlでファイルから値を作成して作成 —from-file
      • kubectlで envfileから値を参照して作成する —from-env-file
      • kubectlで直正値を渡して作成する —from-literal
      • マニフェストから作成する -f
    • kubectlでファイルから値を作成して作成
      • 改行コードをいれない
    • kubectl で envfile から値を参照して作成する
      • --from-env-file
      • でtxtをわたしてさくせい
    • kubectlで直正値を渡して作成する
      • --from-literal
      • もじをそのまま
    • マニフェストファイルの場合
  • TLSタイプのSecret
    • Ingressリソースから作成することが基本
    • 秘密鍵と証明書のファイルから作成
  • DockerレジストリタイプのSecret
    • プライベートリポジトリの場合、Dockerイメージ取得時には認証が必要
    • この認証情報をSecretとして指定して利用可能
    • kubectlから直接作成
    • イメージ取得時のSecretを利用
      • spec.imagePullSecrets
      • これは複数指定可能
  • Secretの利用
    • 大きく分けて下記の2パターンがあります
      • 環境変数を渡す
        • Secretの特定のKeyのみ
        • SecretのすべてのKey
      • Volumeとしてマウントする
        • Secretの特定のKeyのみ
        • SecretのすべてのKey
  • 環境変数として渡す
    • 環境変数として、secretkeyRefで参照可能
    • 動的なSecretの更新
      • Volumeマウントを利用したSecretでは一定期間ごとにkube-apiserverに変更クォ確認して変更がある場合はファイルの変更をおこなっている
    • kubesecのインストール
      • kubesecを利用することでSecretの暗号化がかのう
      • Google Cloud KMSを利用して暗号化可能
    • Secretは分散KVSのetcdで保存されている
    • etcdに保存されている

7.4 ConfigMap

  • Genericタイプのsecretと同じ方法で作成する
    • kubectlでファイル参照
    • kubectlで直接値を渡してさくせい
    • マニフェストから作成
  • kubectl でファイルから値を参照して作成する
    • --from-fileで作成する
    • ファイル名がKey名となる
    • --from-file=nginx.conf=sample-nginx.confとか
    • kubectl create configmap --save-config sample-configmap --from-file
  • 値を直接渡す
    • kubectl create configmap --save-config web-config --from-literal = connection.max = 100 --from-literal = connection.min = 10
  • マニフェストから作成する
  • ConfigMapを利用する
    • 大きく分けて下記の2パターンがあります
      • 環境変数を渡す
        • Secretの特定のKeyのみ
        • SecretのすべてのKey
      • Volumeとしてマウントする
        • Secretの特定のKeyのみ
        • SecretのすべてのKey
    • ほぼSecretと同じ

7.5 PersistentVolumeClaim

  • Volume, PersistentVolume, PersistentVolumeClameの違い
    • Volume
      • あらかじめ利用可能なボリュームをマニフェストに直接指定することで利用可能にするもの
      • 利用者がKubernetes上から新規でボリュームを作成したり、既存のボリュームを削除することはできない
    • PersistentVolume
      • 新規のボリュームの作成や、既存のボリュームの削除などを行うことが可能です。具体的には、マニフェストなどからPersistentVolumeリソースを別途作成する形になります。
    • PersistentVolumeClame
      • その名のとおり作成されたPersistentVolumeリソースの中からアサインするためのリソース
      • PersistentVolumeはクラスタにボリュームを登録するだけなので、実際にPodか ら利用するにはPersistentVolumeClaimを定義して利用する必要がある
      • Dynamic Provisioning機能を利用した場合は、PersistentVolumeClaimが利用されたタイミングでPersistentVolumeを動的に作成することが可能

7.6 Volume

  • 様々なpluginが存在。
  • Secret、ConfigMapもVolumeプラグインの一種
    • emptyDir
    • hostPath
    • downwardAPI
    • projected
    • nfs
    • iscsi
    • cephfs
  • Podに対して静的な領域に指定する形になるのでプラグインによっては競合に気をつけること
plugin
特徴
emptyDir
Terminateされると消える
ホスト上の任意の領域をマウントできるわけではない
hostPath
Node上の領域をコンテナにマッピングするプラグイン
ホスト上納任意の領域をマウントできる
typeには
  • Directory
  • DirectoryOrCreate
  • File
  • Socket
  • BlockDevice
から選択
セキュリティ的にはNG
terminateしても消えない
Podの/srv, ホストの/etcマウント
downwardAPI
fieldRef, resourceFieldRefで利用
Pod情報などをファイルとして配置する
projected
projectedは、Secret／ConfigMap／ downwardAPI／serviceAccountTokenのボリュームマウントを1箇所のディレクトリに集約するプラグイン

7.7 PersistentVolume (PV)

  • 永続化ボリュームとして整備
  • リソースとして個別に作成してから利用します。
  • PersistentVolumeの種類
    • ネットワーク越しにアタッチする
    • GCe Persistent DIsk
    • AWS Elastic Block Store
    • NFS
    • iSCSI
    • Ceph
    • Openstack Cinder
    • GlusterFS
  • PersistentVolumeの作成
    • 設定値
      • ラベル
      • 容量
      • アクセスモード
      • Reclaim Policy
      • マウントオプション
      • StorageClass
      • 各プラグインに特有の設定
    • ラベル
      • ラベルをつけないと、割当を行う際に目当てのボリュームを指定することが困難
      • type, speedとか
    • 容量
      • 3GBの容量を要求した場合は、一番近いものが選ばれる。差分は死ぬ？
    • アクセスモード
      • ReadWriteOnce RWO
        • 単一ノードからR/W
      • ReadOnlyMany ROM
        • 複数ノードからReadが可能
      • ReadWriteMany RWX
        • 複数ノードからRW
    • Reclaim Policy
      • 利用し終わった後の処理
        • Delete
        • Retain
        • Recycle
    • StorageClass
    • マウントオプション

7.8 PersistentVolumeClaim

  • PersistentVolumeを要求するリソース
  • 指定した条件にあった永続化ボリュームを割り当てる
  • PersistentVolumeClaimの設定
    • ラベルせレクタ
    • 容量
    • アクセスモード
    • Storageclass
  • 作成
  • Podからｓの利用
    • spec.volumesにpersistentVolumeClaim.claimNameを指定
  • Dynamic Provisionning
    • StorageClassをリソースを作成。
    • Dynamic Provisioning用のStorageClassを指定してPersisitentVolumeClaimを作成する
    • GCEにおけるStorageClass
      • type
      • replication-type
      • zone
      • zones
  • ボリューム拡張
    • α版
    • PersistentVolumeClaimのリサイズを行うには事前にStorageClassにallowVolumeExpantion:trueを設定しておき、そのStorageClassを元にPersistentVolumeClaimを作成する必要があります。StorageClassは、下記のように定義します。
  • StatefulSetでのわーくろーど
    • spec.volumeClaimTemplateがStatefulSetには存在している。
    • かってにスケールする

7.9 volumeMountsで利用可能なオプション

  • ReadOnly
    • boolean
  • subPath
    • volumeMounts.subPathで指定

第8章 ClusterリソースとMetadataリソース

8.1 ClusterリソースとMetadataリソースの概要

  • Clusterリソースはクラスタの挙動を制御するためのリソース。下記10種類が利用可能
    • Node
    • Namespace
    • PersistentVolume
    • ResourceQuota
    • ServiceAccount
    • Role
    • ClusterRole
    • RoleBinding
    • ClusterRoleBinding
    • NetworkPolicy
  • Metadataリソースはクラスタ上にコンテナを起動させるのに利用するリソースです。4種類。
    • LimitRange
    • HorizontalPodAutoscaler
    • PodDisruptionBudget
    • CustomResourceDefinition

8.2 Node

  • Nodeを表示
    • kubectl get nodes -o wide
  • yaml形式
    • kubectl get nodes gke-k8s-default-pool-37a6668b-00bq -o yaml
  • 割当可能なリソース残量を確認するにはAllocatable から現在のリソースの使用量を差し引きするような必要があります。
  • リソース使用量を確認
    • kubectl describe node gke-k8s-default-pool-37a6668b-00bq 
  • k8sではNodeの状態を様々な側面から確認
  • Nodeのステータスがreadyかどうかはstatus.conditionsで確認可能
  • docker imageも確認可能
  • のーどのバージョン情報はstatus.nodeInfoに記載

8.3 Namespace

  • 仮想的なクラスタの分離機能
  • 初期状態では下記の3つ
    • default
    • kube-system
    • kube-public
  • 自分で作成することも可能
    • リソースのクォータを設定するresourceQuota
    • 認証を行うRBAC

8.4 まとめ

  • NodeとNamespaceは重要だゾ！

第9章 リソース管理とオートスケーリング

9.1 リソースの制限

  • リソース制限は必須
  • CPUは周波数による指定ではなく1 vCPUを1000millicoresとする単位で指定する。
  • リソース種別
    • CPU：1 = 1000m = 1 vCPU
  • メモリ
    • 1G = 1000M (1Gi = 1024 Mi)
  • Requestは下限
  • Lmitsは上限
  • kubectl get nodes -o yaml ではノードの反りソース料と割当可能リソース量のみ
  • kubectl describe nodeを利用する必要がある
  • GPUなどのリソース制限
  • オーバーコミットとリソース不足
    • リソース不足の量までスケールしても動かない
    • それはそう

9.2 Cluster Autoscalerとリソース不足

  • Kubernetesでは食らうsた自体をオートスケールする機能がある
  • 需要に応じてNodeを自動追加していく
  • Pending状態のPodができたタイミングで初めてCluster Autoscalerが起動する
    • RequestとLimitを適切に設定しないと逼迫時にスケールしなかったり、平穏時にスケールしたりする
      • Request（最低限要求）が高すぎると、新規ノード払い出しがひつようになったりする
      • Requestを低くしすぎてもだめ。低すぎると各PODのリソースを食らいつくすが、requestsで設定している量が小さいためノードのリソース状況に余裕があるように見えるため
  • 心がけること
    • RequestsとLimitsに顕著な差をつけないこと
    • Requestsを大きくしすぎないこと

9.3 LimitRangeによるリソース制限

  • LimitRangeはNameSpaceごとに制限をかける
  • 設定可能な項目
    • default
      • デフォルトのLimits
    • defaultRequest
      • デフォルトのRequests
    • max
      • 最大リソース
    • min
      • 最小リソース
    • maxLimitRequestRatio
      • Limit/Requestsの割合
  • LimitRangeを設定可能なリソースは下記の3種類
    • Pod
    • Container
    • PersistentVolumeClaim
  • 一つのLimitRangeで複数のTypeに制限をかけることも可能
  • デフォルトで作成されているLimitRange
    • Requestsすら指定していない場合は、スケジューラは永遠にそのノードにスケジュールし続ける
    • GKEではデフォルトで設定されている
      • kubectl get limitranges limits -o yaml
    • 消すとき
      • kubectl delete limitranges --all
  • Containerに対するLimitRange
    • 設定後に下記コマンドでコンテナの状況をみると反映されていることがわかる
      • kubectl get pods sample-pod -o json | jq .spec.containers.resources
    • こえるリソース、不足したリソースを指定するとエラーになる
      • Error from server (Forbidden): error when creating "sample-pod-upper.yaml": pods "sample-pod-upper" is forbidden: maximum memory usage per Container is 1Gi, but limit is 2Gi
  • Podに対するLimitRange
  • PersistentVolumeClaimに対するLimitRange

9.4 QoS Class

  • Pod には Request/Limits の設定に応じて自動的に QoS Class の値が設定される
  • 自分が設定するものではなく自動で設定されるもの
    •  Best Effort:3
      • どちらも未指定
    • Guaranteed:1
      • Requests/Limits が同じでCPUとメモリの両方が指定されている
    • Burstable:2
      • Guranteedがみたされず、1つ以上のRequests/Limitsが設定されている
  • 上の順序でPodが停止される
  • QoS Class は Pod の status.qosClassで確認することが可能
  • 下記コマンドで確認可能
    • kubectl get pods -o custom-columns="NAME:{.metadata.name}, QoS Class:{.status.qosClass}"

9.5 ResourceQuotaによるNamespaceのリソースクォータ制限

  • Namespace = 仮想k8sクラスタ
  • Namespaceごとの
    • 作成可能なリソース数
    • リソース使用量の制限
  • 作成可能なリソース宇野制限
    • count/RESOURCE.GROUP
    • この記法を用いてクォータの制限をかけることが可能になった
  • リソース使用量の制限
    • Storageに関してはlimitsは存在しない

9.6 HorizontalPodAutoscaler (HPA)

  • Deplouyment, ReplicaSet, ReplicationControllerのレプリカ数をCPU不可に応じて自動スケールするリソース
  • 必要なレプリカ数 = ceil(sum(Podの現在のCPU利用率)/targetAverageUtilization)
  • CPU使用率は各Podの1分間の平均値
  • スケールアウトの条件式
    • avg(Podの現在のCPU使用率) / targetAverageUtilization > 1.1
  • スケールインの条件式
    • avg(Podの現在のCPU使用率) / targetAverageUtilization < 0.9
  • 別途prometheusなどの監視ツールと連携することが可能

9.7 VerticalPodAutoscaler (VPA)

  • コンテナに割り当てるリソースを自動的にスケールさせる
  • スケールアップ。垂直スケーリング。

第10章 ヘルスチェックとコンテナライフサイクル

10.1 ヘルスチェック

  • spec.restartPolicyに従ってPodの再起動を行う
  • その他にも詳細な設定を実施することが可能
  • Liveness Probe と Readiness Probe 2出位のヘルスチェック機構
    • 設定内容は全く同じ
    • spec.containersに設定する
種類
役割
失敗時の挙動
Liveness Probe
Podが正常に動作しているかの確認
（プロセスにバグが有った場合などに再起動できるように）
Pod の再起動
Readiness Probe
Podがサービスインできる準備ができているかの確認
トラフィックを流さない
  • 通常のロードバランサからのNode へのヘルスチェックはICMPによる簡易チェックのみ。Podの状態をチェックする場合は上記のProbe機構を利用する必要がある
    • Internet Control Massage Protocol
  • 三種類のヘルスチェック方式
    • ともに3種類のチェック方式を利用可能
      • exec
        • コンテナを実行し、Exitコードが0でなければ失敗
        • コマンドを指定しておく
      • httpGet
        • HTTP GET リクエストを実行し、ステータスが2xx, 3xxでなければ失敗
        • パスやポートを指定して、ホスト、ヘッダーとかも指定
      • tcpSocket
        • TCPセッションが確立できなければ失敗
        • ポートを指定
  • ヘルスチェックの間隔
    • 設定項目は5つ
      • initialDelaySeconds
        • 初回ヘルスチェック開始までの遅延
      • periodSeconds
        • ヘルスチェック間隔
      • timeoutSeconds
      • successThreshold
        • 成功と判断するまでのチェック回数
      • failureThreshold
        • 失敗と(ry
  • ヘルスチェックの作成
  • Liveness Probeの失敗
$ kubectl get pods sample-liveness --watch
NAME              READY   STATUS    RESTARTS   AGE
sample-liveness   1/1     Running   1          71s
sample-liveness   1/1     Running   2          2m33s
sample-liveness   0/1     CrashLoopBackOff   2          2m43s
sample-liveness   1/1     Running            3          2m58s
    • kubectl describeで詳細を確認可能
kubectl get pods sample-readiness --watch
NAME               READY   STATUS    RESTARTS   AGE
sample-readiness   1/1     Running   0          19m
sample-readiness   0/1     Running   0          19m
sample-readiness   1/1     Running   0          20m

10.2 コンテナのライフサイクルと再始動 (restartPolicy)

10.3 Init Containers

  • Pod内でメインコンテナを起動する前に別のコンテナを起動するための機能。
  • セットアップ用のスクリプトなどをコンテナに含まずにやれる
  • spec.initContainers.commnad
    • 複数選択可能
    • spec.containers よりはやく実行される
  • 利用シーン
    • リポジトリからファイルなどを取得する処理
    • コンテナの起動を遅延させる処理
    • 設定ファイルを動的に生成する処理
    • Serviceが作成されているかの確認
    • その他メインコンテナを起動する前のチェック作業
  • https://github.com/Rtaro02/studyk8s/blob/master/sample-initcontainer.yaml
  • initConatainersの順序性は担保される

10.4 起動時と終了時に任意のコマンドを実行する (postStart/preStop)

10.5 Podの安全な停止とタイミング

  • Podの削除には何段階かに渡って処理が実行されている
  • 起動中のPodの削除要求がAPIサーバーに届くと、非同期に
    • preStop処理＋SIGTERM処理
    • Serviceからの除外設定
  • が実行される
  • リクエスト断が発生する可能性がある。これをなくすには
    • preStop処理＋SIGTERM処理で待機
    • preStop処理＋SIGTERM処理でリクエストを受けつつ停止処理を行う
  • spec.termination.GracePeriodSeconds という設定値以内にpreStop + SIGTERMを終了させる必要がある

10.6 リソースを削除したときの挙動

  • 親リソースさくじょされたばあいには、小リソースなども削除するためのガベージコレクションが発生する
  • PodにはどのResplicaSetから作成されたかを判別するために、自動的に情報が保存されている
$ kubectl get pods sample-rs-55zmv -o json | jq .metadata.ownerReferences
[
  {
    "apiVersion": "apps/v1",
    "blockOwnerDeletion": true,
    "controller": true,
    "kind": "ReplicaSet",
    "name": "sample-rs",
    "uid": "f0ee7ed8-a857-4c4e-b2b0-db6ffa5fb759"
  }
]
  • ReplicaSetを削除したときの挙動
  • backとforeはカスケーゾ削除と呼ばれている（結果的に依存するPodの削除を行うため）
    • Background (Default)
      • ReplicaSet: 直ちに削除
      • Pod: ガベージコレクタ、バックグラウンドで非同期に削除
    • Foreground
      • ReplicaSet: 直ちに削除しない、設定する
      • Pod: ガベージコレクタがフラグ立てたものだけを削除。falseはバックグラウンド処理で削除
      • すべて終わったらReplicaSetを削除する
    • Orphan
      • ReplicaSet削除時にPodの削除を実施しない
  • 現状はForegroundはなし
  • Backgroudで消したい場合は
    • kubectl delete --cascade=true replicaset sample-rs
  • カスケードオプションをfalseにすればPodを残したままReplicaSetを削除することが可能

第11章 メンテナンスとノードの停止

  • ノード停止時にはPod停止が必要
  • SIGTERM, SIGKILLのシグナルに対応したアプリケーションを作成する必要がある

11.2 スケジューリング対象からの除外と復帰

  • ノードは下記のステータスを持つ
    • SchedulingEnabled
    • SchdulingDisabled
  • SchdulingDisabled になったノードはスケジューリング対象から外れ、ノード上でPodが新規作成されなくなります。
  • Disableにするには
    • kubectl cordon
  • Endleにするには
    • kubectl uncordon

11.3 ノードの排出処理によるPod退避 (drain)

  • ステータスをDisabledにしてもPodは動き続ける
  • 排出処理がkubectl drainコマンド
  • --forceオプション
    • deploymentなどで管理されていない単体のPodを削除する場合
  • --delete-local-data
    • local storageを使っているPodを削除しようとした場合
  • --ignore-daemonsets
    • デーモンセットが管理しているPod

11.4 PodDisruptionBudget(PDB)による安全な退避

  • PodDisruptionBudgetはノードが排出処理を行う際に、Podを停止することができる最大数を設定するリソース。
  • 全部停止しちゃうとダウンタイムが発生する可能性がある
  • 最小の起動数と、最大の停止数を設定
  • 教科書どおりやったら、両方設定できなかった！
  • パーセンテージでの対応も可能

第12章 高度で柔軟なスケジューリング

12.1 高度なスケジューリングとAffinity/Anti-Affinity

  • スケジューリングもNodeやPodのラベルを使うことで実現
  • スケジューリングには下記がある
    • Podのスケジューリング時に特定のNodeを指定する方法
    • Nodeに対して汚れ(tiant)をつけておき、それを許容(Tolerations)できうPodのみスケジューリングを許可する方法
  • スケジューリングで起動する方法
    • nodeSelector
      • 簡易的なNode Affinity機能
    • Node Affinity
      • 特定のノード上だけで実行する
    • Node Anti-Affinity
      • 特定のノード以外で実行する
    • Inter-Pod Affinity
    • Inter-Pod Anti-Affinity

12.2 ビルトインノードラベルとラベルの追加

12.3 nodeSelector (Simplest Node Affinity)

12.4 Node Affinity

  • Podを特定のノード上へスケジュールするポリシー
  • spec.affinity.nodeAffinityに設定
  • requiredDuringSchedulingIgnoredDuringExecution
    • 必須のスケジューリングポリシー
  • preferredDuringSchedulingIgnoredDuringExecution
    • 優先的に考慮されるスケジューリングポリシー
  • kubectl -L=disktype,cputype,disksize get node
  • 優先条件を満たせばそこのノードにスケジューリングされる
  • 優先条件満たしていても、Nodeが停止状態の場合には必須条件を満たしたノードへスケジューリングされる
  • 必須条件を満たせない場合はスケジューリングに失敗する
  • 必須条件
    • nodeSelectorTerms配列
      • 複数指定可能
      • OR条件
      • matchExpressions配下はAnd条件
  • 優先条件
    • preferredDuringSchedulingIgnoredDuringExecution配列
      • 複数指定可能
      • それぞれスケジューリングされるが、Weightで指定した量で分配される
      • matchExpressions配下はAND条件

12.5 matchExpressionsのオペレータとset-based条件

  • keyで指定したラベル名、オペレータで一致するものを指定、valueで値を指定
  • 利用可能なオペレータ
    • In
      • いずれかと一致
    • NotIn
      • どれにも一致しない
    • Exists
      • ラベルが存在すればOK
    • DoesNotExists
      • ラベルAが存在しない
    • Gt
      • 値が指定したものより大きい
    • Lt
      • 値が指定したものより小さい

12.6 Node Anti-Affinity

  • 特定のノード以外にスケジューリングするポリシー
  • 厳密には存在しない
  • spec.affinity.nodeAffinityの条件部分に否定形のオペレータを指定することで実現

12.7 Inter-Pod Affinity

  • 特定のPodが実行されているドメイン上へのPodをスケジューリングするポリシー
  • spec.affinity.podAffinityを指定
  • Pod同士を近づけて配置することができるので、Pod間のレイテンシを下げることが可能
  • topologyKeyでどのドメインをスケジューリング対象にするかを指定する
    • sample-appのラベルに一致するPodと同じノード上にスケジューリングする
  • failure-domain.beta.kubernetes.io/zoneにした場合は同じゾーンにスケジューリングする
  • 必須と優先を設定可能
  • スケジューラーは配置を制御するだけ

12.8 Inter-Pod Anti-Affinity

  • 特定のPodがいないドメイン上で動作させるポリシー
  • spec.affinity.podAntiAffinityに設定可能

12.9 複数の条件を組み合わせたPodのスケジューリング

12.10 TaintsとTolerations

  • 汚れTaintsをつけてそれを許容できるかどうかでデプロイする
  • 条件に合致しない場合にはあとからもそのPodを排除することができるようになった
  • 設定方法
  • 下記で設定
    • kubectl tiant
  • Key, Valueは任意
  • 設定できるEffect
    • PreferNoSchedule
      • 可能な限りスケジューリングしない
      • 条件にマッチしなくても、他に配置可能なノードがない場合はスケジューリング候補になる
    • NoSchedule
      • スケジューリングしない
      • すでにスケジューリングされているPodはそのまま
      • 条件にマッチしない場合はスケジューリングを許可しない
    • NoExecute
      • 実行を許可しない
      • すでにスケジューリングされているPodは停止
      • 条件にマッチしない場合はスケジューリングもせず、起動済みPodも停止する
  • Torerationを指定したPodの起動
    • PodのTorerationsはspec.tolerationsで指定する
    • オペレータの種類
      • Equal
      • Exists
        • keyが存在する
    • 未指定の場合はすべてのノードにスケジューリングされる
  • NoExecuteの一定時間の許容
    • 一定時間だけ許容する
    • spec.tolerations.tolerationsSecondsで指定
  • 複数のTaintとTolerations
    • 複数指定も可能だが、全て満たさないといけないことに注意

12.11 PriorityClassによるPodの優先度と退避

  • 優先スケジューリング
  • valueの値によって優先順位がきまる
  • globalDefaultはpriorityClassが指定されていない場合のデフォルト設定となる
  • 複数ある場合は優先順位が低いものがデフォルト
  • 退避の際には、、、
    • Affinituなどのスケジューリング機能が満たされるかどうかを判断する
    • InterPodAffinityと連携すると、優先度低によりPodが退避されてそれによりスケジューリング対象外になる可能性があるので注意

12.12 その他スケジューリング

  • 独自スケジューラーを作成することも可能

第13章セキュリティ

13.1 ServiceAccount

  • UserAccount, ServiceAccountがある
  • UserAccount
    • GKEはGCPアカウントとリンクしている。
    • クラスタレベルの管理
  • ServiceAccount
    • ｋ８ｓの世界
    • Pod起動時には１つわりあてられる
    • 指定しない場合はデフォルトが割当られる
  • ServiceAccountの作成
    • コマンドで作成
      • kubectl create serviceaccount sample-servicesaccount
    • SecretであるimagePullSecretsを設定する場合はkubectl patchもしくはマニフェストで
    • 作成時には指定しなかったsecrets という項目の存在。自動的に作成される。
    • sample-serviceaccount-token-46d24 ってかんじで。
    • このtokenを利用してkubernetes apiへの認証情報として利用することが可能
    • Podに割り当てたServiceAccoutに割り当ててある権限がそのままPodに割り当てる権限となる
    • Podに割り当てる場合はsepc.serviceAccountNameを指定
    • 下記に証明書などがおいてある
      • kubectl exec -it sample-serviceaccount-pod -- ls /var/run/secrets/kubernetes.io/serviceaccount/
  • トークンの自動マウント
    • トークンの自動マウントを無効化することも可能
    • automountServiceAccountTokenをfalseに設定する
    • Podでも設定可能
    • 両方で設定されている場合はPodの設定が優先される
    • クライアントライブラリと認証
      • ServiceAccountのトークンを利用する場合 (In-ClusterConfig)
    • kubeconfigの認証情報を指定する場合
  • Dockerレジストリ認証情報の自動設定

13.2 RBAC (Role Based Access Control)

  • どういった操作を許可するのかを定めたRoleを作成し、ServiceAccountなどのUserに対してRoleを紐付けることで権限を管理する
  • Role / RoleBinding / User
  • RBACには
    • RoleBinding
    • ClusterRoleBinding
  • RoleとClusterRole
    • プリセットで用意されているClusterRole
      • cluster-admin
        • すべてのリソースを管理可能
      • admin
        • ClusterRoleの編集＋NamespaceレベルのRBAC
      • edit
        • ReadWrite
      • view
        • ReadOnly
    • Role作成時にはrules.verbで指定する
      • *
        • すべての処理
      • create
      • delete
      • get
      • list
      • patch
        • 一部変更
      • update
      • watch
        • 変更の追従
    • Role
      • RoleはNamespaceを指定して作成する
        • apiGroupが複数あるという点
        • すべてのDeploymentリソースを対象としてRoleを作成する場合はapiGroupsには注意して下さい
      • deploymentとdeployment/scaleのリソースがある。desployment/scaleがない場合には、scalingの処理を行うことができない
    • ClusterRoleの作成
      • nonResourceURLsはへるちぇとか
    • ClusterRoleのAggregation
      • aggregationRule.clusterRoleSelectors.matchLabelsで設定したsub-clusterroleを設定可能
      • sub-roleをルールを削除すると反映される
  • RoleBindingとClusterRoleBinding
    • 構成はClusterRoleBindingとほぼ同じ
    • RoleBindingの作成
    • Deploymentが許されているもののみ実行可能
    • deployment/scaleまでやっていればdeploymentのスケールが可能
    • replicasetのscaleはできない

13.3 SecurityContext

  • ここのコンテナに対するセキュリティ設定
    • privileged
      • 特権
    • capabilities
      • ケイパビリティの追加と削除
    • allowPrivilegeEscalation
      • コンテナ実行時に親プロセス以上の権限を与えるかどうか
    • readOnlyRootFilesystem
      • rootファイルをリードオンリーにするかどうか
    • runAsUser
    • runAsGroup
    • runAsNonRoot
    • seLinuxOptions
  • 特権コンテナの作成
    • spec.containers.securityContext.privilegedをtrueにする
  • capabilitiesの付与
    • 特権コンテナではホストと同等のCapabiltyが追加されるが、細かくコンテナに付与、剥奪できる
  • rootファイルシステムのReadOnly化
    • コンテナイメージに含まれているファイルをReadOnlyにすることが可能

13.4 PodSecurityContext

  • Podに対すセキュリティ設定
    • runAsUser
    • runAsGroup
    • runAsNonRoot
    • supplementalGroups
      • プライマリGIDに追加で付与するGIDのリストを指定
    • fsGroups
    • sysctls
    • seLinuxOptions
  • 実行ユーザーの変更
    • Entrypointの実行ユーザーの変更行うことが可能
  • rootユーザーでの実行制限
    • nginxのようなroot要求のコマンドは失敗する
  • ファイルシステムのグループ設定
    • マウントしたVolumeはroot:rootになる
    • 実行ユーザー変更したときに権限がない場合があるので、ファイルシステムのグループ設定を実施する
  • sysctlによるカーネルパラメータの設定
    • カーネルパラメータはPod内のコンテナで共有
    • safe と unsafe に分類

13.5 PodSecurityPolicy

13.6 NetworkPolicy

13.7 認証/認可とAdmission Control

  • APIサーバーにリクエスト制御を追加
  • Authentication/AuthN 認証
  • Ahthentication/AuthZ 認可

13.8 PodPreset

  • デフォルト値を入れる
  • ラベルにマッチするpodにデフォルトの定義を入れる
  • Podpresetの内容はPodの個別定義で書き換えされないので注意

第14章 マニフェストの汎用化を行うオープンソースソフトウェア

14.1 マニフェストの汎用化

  • k8sではyamlファイルを書いてkubectlで管理
  • 大規模になればなるほどしんどくなる
  • マニフェストの汎用化という処理が必要になってくる

14.2 Helm

  • kubernetesのパッケージマネージャ
  • パッケージ = Chart
  • tiller podを利用する
  • 基本的にはstableのChartのみが影響
  • incubatorのリポジトリを手動で追加が必要
  • リポジトリ更新
    • helm repo update
  • リポジトリ検索
    • helm search data
  • 詳細情報
    • helm inspect stable/datadog
  • インストール
    • helm install xxxx
  • valueファイル
    • ファイルをりようしてインストール
    • helm install xxxx --value values.yaml
  • 独自のChartもつくれる

14.3 Ksonnet

  • JSONベース
  • コンセプト
    • Prototype
      • Componentのもととなるひながた
    • Component
      • Prototypeに対してパラメータを指定して具体化した実体
    • Application
      • 複数のComponentから成り立つアプリケーション
    • Environment
  • 複数のKubernetes環境に同じアプリケーションをデプロイすることを目的としている

第15章 モニタリング

15.1 Kubernetesにおける監視

  • Datadog, Prometheus

15.2 Datadog

  • DaemonsetでAgentを各ノード上に起動する
  • kube-state-merticsを追加でインストール連携が推奨

15.3 Prometheus

  • CNCFがホストしているもの
  • 下記で構成
    • Prometheus Server
      • Alert Manager
      • Exporter
      • Push Gateway

第16章 コンテナログの収集

16.1 コンテナ上のアプリケーションログの出力

  • クラスタ外部にログを転送
  • アプリケーションが特定ンのファイルにログを書き出す
  • アプリケーションからライブラリを使って直接外部に転送する
  • ログ欠損が内ように永続化領域に保存しよう

16.2 Fluentdによるログ集約

  • DaemonSetを利用してPodを起動する
  • 起動するだけで転送可能なので、疎結合でいける
  • Fluentbitってのもある。IoT向けだけど、軽量なのでfluentdに利用可能

16.3 Datadog Logsによるログ集約

  • Datadogと合わせて収集可能

第17章 Kubernetes環境でのCI/CD

17.1 Kubernetes環境でのCI/CD

17.2 Spinnaker

17.3 Skaffold

  • コンテナイメージのビルド
  • コンテナイメージのプッシュ
  • Kubernetesへのデプロイ

17.4 JenkisX

17.5 GitOps

第18章 マイクロサービスアーキテクチャとサービスメッシュ

18.1 マイクロサービスアーキテクチャとは

  • 適切に分割する困難さ
  • モニタリングが難しい

18.2 サービスメッシュ

  • よくあるやつ
    • Istio
    • Conduit
    • Linkerd
  • Pod間の通信経路にプロキシを挟むことでトラフィックのモニタリングやコントールする
  • Traffic shifting
    • 99%を古いDeploymentへ
    • 1%を新しいDeploymentへ
    • カナリアリリース
  • Circuit Breaker
    • 転送元の障害が発生したときに止めるのがサーキットブレイカー
  • Fault Injection
    • 意図的にリクエストを遅延させたり失敗させたりする
    • 失敗時に適切に起動するかをみる
  • Rate Limit
    • リクエスト制限
    • e.g.) 10000 requests/second
  • Retry
    • アプリケーションでやらなくてもリトライ処理をやってくれる

18.3 Linkerd

  • App A, App B, AppBの例
    • A → B → Cに流れる
    • l5dを各Nodeに立ち上げておく
      • イン・アウトともにl5d経由でリクエストする
      • 下記の流れ
        • l5d A
        • App a
        • l5d a
        • l5d b
        • app b
        • l5d b
        • l5d c
        • app c
    • トラフィックコントロールを行うには namerdを利用する動的に設定が可能

18.4 Conduit (Linkerd v2)

18.5 Istio

第19章 Kubernetesのアーキテクチャを知る

  • ７つのコンポーネントからなる
    • etcd
    • kube-apiserver
    • kube-scheduler
    • kube-controller-manager
    • kubelet
    • kube-proxy
    • kube-dns

19.2 etcd

  • etcdはGo言語で記述された設定情報の共有とサービス検出のための分散KVS
  • etcdのデータを守ることが最も大切
  • クラスタ化するほうがよい
  • 奇数台にしたほうがよい

19.3 kube-apiserver

  • kubectlの対向
  • kube-apiserverはPodリソースの情報をetcdに書き込む。
  • このときには起動ノード情報は決まっていない
  • kube-schedulerがapi経由で書き込みすることでノードがきまる
  • kubeletがノード情報が自身に割り当てられている起動していないPodがあれば起動する
  • apiserverを中心にやっている

19.4 kube-sheduler

  • Nodeのステータス、Affinity情報をもとに起動ノードを決定する

19.5 kube-controller-manager

  • Podを登録する
  • 実際のスケジューリングはschedulerが実施

19.6 kubelet

  • dockerなどのコンテナランタイムと連携してこんてなの起動停止を実施
  • つかえるの
    • docker-shim
    • containerd
    • cri-o
    • Frakti
    • rktlet

19.7 kube-proxy

  • 転送方式
    • ユーザースペースで処理
    • iptablesで処理
    • IPVSで処理

19.8 kube-dns

19.9 その他コンポーネント

19.10 CustomResourceDefinitionとOperator

  • 独自リソースを拡張することができる

第20章 kubernetesとこれから

20.1 取り巻く標準化

  • OCI (Open Container Initiative)
    • コンテナの標準仕様
  • CRI (Container Runtime Interface)
    • k8sとコンテナランタイムをつなぐインターフェース
  • CSI (Container Storage Interface)
  • CNI (Container Network Interface)
    • ネットワークインターフェース
      • Project Calico
      • Cilium

20.2 Kubernetesとエコシステム

  • ミドルウェアのk8s対応、周辺のエコシステムができてきた
  • k8sクラスタ上に展開するXaaS
    • Vitess
      • MySQL環境をデプロイ
    • NATS
      • メッセージキュー環境をデプロイ
    • Rook
      • Cephなどの分散ストレージ環境尾をデプロイ
    • Kubeflow
  • Serverless
    • OpennFaas
    • Kubeless
    • Fission
    • Knative
  • Service Broker, Service Catalog