Google Kubernetes Engine

https://cloud.google.com/kubernetes-engine/

関連ページ:

Getting Started

Documentation

ベストプラクティス

仕様

Quota

https://cloud.google.com/kubernetes-engine/quotas

Last updated at 2020-04-13

  • GKEクラスタごと
    • クラスタあたりの最大ノード数: 5,000
    • ノードプールあたりの最大ノード数: 1,000
    • ノードあたりの最大ポッド数: 110

限定公開クラスタ

Documents:

要点:

  • ノードは内部IPアドレスのみを持つため、インターネットから隔離される
  • 限定公開クラスタでは、マスターへのアクセスを制御できる
  • LB経由で受信トラフィックを受けられる。また、内部LB経由でVPC内のトラフィックを受けることもできる
  • 外と通信したいときは、上記の「Example GKE Setup」にあるように、Cloud NAT + Cloud Routerをセットアップする

Tips:

  • (2019-12-02現在) gcloud container clusters create コマンドでは --enable-private-nodes --master-ipv4-cidr <CIDR> オプションをつける

制限事項

限定公開クラスタの作成 | Kubernetes Engine ドキュメント | Google Cloud#要件、制約、制限

Horizontal Pod Autoscaler

HPA.

参考:

コンテナネイティブの負荷分散

コンテナ ネイティブの負荷分散を使用する | Kubernetes Engine のドキュメント | Google Cloud

TL;DR:

  • ネットワークエンドポイントグループ(NEG)を作成して、Podに均等にトラフィックを分配できる
  • 従来の方式だとインスタンスグループ経由のアクセスで、iptablesを介してPodにアクセスしており、余分なネットワークオーバーヘッドが発生していた

既知の問題（2020-04-27時点）:

  • GKEのガベージコレクションが2分間隔なので、LBが完全に削除される前にクラスタが削除された場合、NEGを手動で削除する必要がある
  • Podのreadinessフィードバックを使っていない場合、ワークロードをデプロイするときや再起動するときに、ワークロードの更新完了に要する時間よりも、新しいエンドポイントの伝播に要する時間のほうが長くなる場合がある

VPCネイティブクラスタ

VPC ネイティブ クラスタを作成する | Kubernetes Engine ドキュメント | Google Cloud

2020-05-04現在、GCPコンソールから作成する場合はデフォルトでVPCネイティブクラスタになるが、REST APIやgcloudコマンドではルートベースクラスタになるので注意。

2つのやり方がある:

  1. 既存のサブネットにクラスタを作成する。アドレス範囲の割り当て方は下の2つ:
    • GKE管理のセカンダリ範囲割り当て
    • ユーザー管理のセカンダリ範囲割り当て
  2. クラスタとサブネットを同時に作成する。セカンダリアドレス範囲の割り当てはGKE管理となる

セキュリティ

クラスタのセキュリティの強化 | Kubernetes Engine ドキュメント | Google Cloud

Secretリソースへのアクセスを制限する

いずれか:

  1. IAMで container.secrets.* の権限を与えない
  • roles/container.viewer なら権限なし
  • roles/container.developer なら権限あり
  1. RBACで権限制御する

参考:

最小権限のGoogleサービスアカウント

https://cloud.google.com/kubernetes-engine/docs/how-to/hardening-your-cluster?hl=ja#use_least_privilege_sa

  • 前提として、Compute Engineのデフォルトサービスアカウントを使わないようにする
  • カスタムサービスアカウントには、最低でも以下の権限が必要:
    • monitoring.viewer
    • monitoring.metricWriter
    • logging.logWriter

How-to

アップグレード

https://cloud.google.com/kubernetes-engine/docs/how-to/upgrading-a-cluster

Tips:

kubeconfigエントリを生成

gcloud container clusters get-credentials [CLUSTER_NAME] [--project PROJECT] [--region REGION]

↑のコマンドは更に、クラスタをデフォルトのkubectlのcontextに設定する。

参考:

ノードプールを作り直す

マシンタイプやサービスアカウントを変えるときなどには、ノードプールの作り直しが発生する。
次の要領でやれば良い:

  1. 新しいプールを作成
  2. ワークロードを新しいプールに移行
  3. 古いプールを削除

ドキュメントでは、 異なるマシンタイプへのワークロードの移行 | Kubernetes Engine のチュートリアル | Google Cloud の手順に従う形になる。

ただし、この手順に愚直に従うとドレインした瞬間に旧プール上のPodがevictionされ、サービス停止することもあり得るので、常時稼働のワークロードであれば、cordonでノードへのスケジューリングを停止した後、Podをスケールさせて新しいプールにPodが配置された後にドレインした方がよさそう。

GKEのノードにSSH

参考:

メンテナンス時間枠と除外枠の設定

メンテナンスの時間枠と除外の構成 | Kubernetes Engine ドキュメント | Google Cloud

  • クラスタやノードのアップグレードが行われる時間枠を設定可能。
  • （たぶん）最短4時間

Docker Hubのイメージを使うには？

公開イメージだったら普通に使える。

プライベートなイメージでも認証情報を渡せば普通に使えるんじゃないかな。

MEMO:

  • 日本語の記事だとミラーしたり、GCRにpushしてる例が多い

参考:

ワークロードを特定のnodepoolで実行する

GKEのノードはnodepoolを表すラベルとして cloud.google.com/gke-nodepool: <nodepool名> が設定されている。
これを用いて、nodeSelector、またはNode Affinityを設定する。

参考:

Topics

Logging

マルチテナント運用

ロギング

Tips:

  • ログシンクを使って、テナントごとにログバケットを分割することができる
    • namespaceによるフィルタを使うことになる

参考

機能

最終更新 2021-03-26: [google,memo,k8s,argocd] Add some notes (5303acbd5)