Kubernetes完全ガイド を読んだので、メモを残しておく。 普段、意識していなかったコマンドや仕組みをまとめておく。

  • サイズの小さなイメージを作りたければ scratch や apline をベースにする
  • ENTRYPOINT と CMD が設定されているときは、$ENTRYPOINT $CMD が実行されるようなイメージ
  • マルチステージビルド：ビルド専用のコンテナでだけ処理を行い、成果物を実行専用コンテナにコピーすることが出来る
  • CNCF ではプロジェクトの成熟度を「Graduated」「Incubating」「Sandbox」の3段階に設定している
  • オンプレで構築する場合はAWS や GCP でのインスタンスサイズが目安になる
  • Flannel：ノード間でオーバーレイネットワークを構成する
  • Docker, Inc. が提供するkubernetes のプレイグラウンドがある
  • kubernetes のリソースは大きくわけて5種類
    • Workloads, Discoverty &LB, Config & Storage, Cluser, Metadata
    • 特に Metadata はクラスタ内で他のリソースを操作するためのリソース（HorizontalPodAutoscaler など）
    • Deployment/CronJob > ReplicationController/ReplicaSet/DaemonSet/StatefulSet/Job > Pod という階層構造がある
    • kubectl get all：ほぼすべてのリソースを一覧取得
    • Stateful Set：0番目の Pod が最初に作られ、最後に削除される
  • kubeconfig
    • clusters、users、contexts の3種類を設定（どれも複数登録可能）
    • context や namespace の切り替えが冗長であれば、kubectx や kubens を使うと良いかも
    • kube-ps1 を使うと cluster と namespace をプロンプトに出力できる
    • source <(kubectl completion bash)などで zsh/bash の補完機能を使える
  • コンウェイの法則：組織図と、マニフェストの管理方法やマイクロサービスのアーキテクチャが似ている
  • kubectl scale：ReplicaSet, ReplicationController, Deployment, StatefulSet, Job, CronJob でスケーリング
  • kubectl apply --prune：実行時にマニフェストから削除されたリソースを検知して、自動で削除
    • CI/CDでは、単純にこのコマンドを投げ続けるだけでよい
    • kubectl apply --prune --all：クラスタ内に存在するすべてのマニフェストを読み込ませないと、漏れがあったリソースが消えてしまい危険
    • kubectl apply --prune -l system=a：基本的にラベルを指定しておく
  • デバッグ
    • kubectl cp：コンテナとローカルマシンの間でファイル転送
    • kubectl port-forward：コンテナとローカルマシンの間でポート転送
    • kubectl -v：デバッグ出力
  • サービスディスカバリ
    • spec.hostAliases：Pod内の全コンテナの/etc/hostsを書き換える
    • Pod内からは同 namespace に含まれるサービスを環境変数から確認できる
    • {service name}.{namespace}.svc.cluster.local でサービスのAレコードが登録されている
    • spec.externalTrafficPolicy=Local とすると Node を跨ぐロードバランシングを行わない
    • Headless Service を使うと、VIP経由のトラフィックのロードバランシングではなく、DNSラウンドロビンによる負荷分散を行う
    • 特定の Node のIPアドレス：ポート番号で受信したトラフィックを外部へ転送するために ExternalIP Service を使える
    • ExternalName Service：事前に設定したCNAMEを返す
  • Ingress
    • Ingress：L7ロードバランサを提供する。Service とは違う位置づけなので、独立したリソース
    • Ingress用Podをデプロイする場合：Ingress Pod 宛の Loadbalancer Service を作っておき、そこから先を L7 ロードバランスする
    • Nginx Ingress は Inress Controller 自体が L7 相当の処理を行う Pod にもなっている（コントローラという名前だが）
  • Secret が定義されたマニフェストは Git リポジトリにアップロードする際に kubesec を使って暗号化できる
  • Dynamic Provisioning を使うと、PersistentVolumeChain が発行されたタイミングで動的に PersistentVolume を作成・割り当て
  • スケジューリング
    • Requests はリソースの下限、Limit はリソースの上限
    • これら2つの差は小さくしておく
    • 基本的に Requests を基準にスケジューリング
    • kubectl describe resourcequota で確認できる
    • Beyond CPU: horizontal pod autoscaling with custom metrics in Google Kubernetes Engine が参考になる
    • postStart/preStop：コンテナの起動後と停止直前に任意のコマンドを実行できる
    • ただ確実に慈善処理を行うなら initContainers を使った方が良い
    • None に対して Taints（汚れ） を付けておいて、Pod がそれを Tolerations（許容）するとうスケジューリング
  • ログを中長期に安定保存するには Fluentd を使って外部に転送する構成を取るのがよい
  • Spinnaker（Netflix）、skaffold（Google） などで CI/CD できる
  • マニフェストファイルのLinter kubeval やユニットテストツール kubetest がある
  • サービスメッシュ
    • マイクロサービス間の通信や経路を制御する考え方
    • Istio／Conduit（Linkerd v2）／Linkerd など
  • etcd
    • クラスタの全ての情報を保存するもの
    • 単一障害店（SPoF）になってはならない
    • Raft の性質上3/5/7台といった奇数台で組むのが良い
    • etcd snapshot でバックアップをとれる
  • Operator Framework を使って独自のリソースを作成できる
  • X as a Service：Vitess（Mysql）、NATS（Queue）、Rook（Ceph）、Kubeflow（ML）