GKE
https://gyazo.com/bd9f9c602c517044455065853508d11f
with gcloud
kubectl へ設定を追加
$ gcloud --project=PROJECT_ID container clusters get-credentials <CLUSTER_NAME> --zone=asia-northeast1-a
で、~/.kube/config 下にいろいろ書かれる
GCE インスタンスの確認
$ gcloud compute instances list
クラスタは GCE インスタンスのあつまりなので 普通に見える
BackendConfig
CRD=Custom Resource Definition
kind: BackendConfig で定義していろいろ GCP プロダクトの設定を書いて
Service から metadata.annotation で参照する
code:kustomize.yaml
---
apiVersion: v1
kind: Service
metadata:
name: manager-service
labels:
env: base
annotations:
cloud.google.com/neg: '{"ingress": true}'
cloud.google.com/backend-config: '{"default": "manager-backendconfig"}'
...
---
apiVersion: cloud.google.com/v1
kind: BackendConfig
metadata:
name: manager-backendconfig
spec:
logging:
enable: true
sampleRate: 1.0
みたいな
Cloud Load Balancing からのヘルスチェック
コンテナ ネイティブの負荷分散を使用しない場合、Service マニフェストでは type: NodePort を使用する必要があります。コンテナ ネイティブの負荷分散を使用する場合は、type: ClusterIP を使用します。
GKE によって Ingress の外部 HTTP(S) ロードバランサまたは内部 HTTP(S) ロードバランサが作成された後に、Ingress によって参照される Service のサービスを提供する Pod の readiness Probe を変更した場合、readiness Probe への変更は、ロードバランサ上の対応するバックエンド サービスのヘルスチェックにコピーされません。
Ingress から X-Cloud-Trace-Context ヘッダが来るか
くる
Workload Identity
code:node_config
node_config {
workload_metadata_config {
node_metadata = "GKE_METADATA_SERVER"
}
}
google_container_cluster にでも google_container_node_pool にでも書ける
前者だと cluster の replace になる
replace ないやとおもって適用したけど 40分かかった
Workload Identity も GCP クライアントライブラリの権限ディスカバリの仕組みの一部という感じ
魔法の技術じゃなくてクライアントライブラリ使っていたら GOOGLE_APPLICATION_CREDENTIALS があれば使う、なければ ~/.config から探す、Metadata Server に問い合わせる、の流れで Metadata Server 叩いて機能している
自前で
Cloud Load Balancing の Ingress から Service への RPS
設定できず常に警告状態になる
1Pod = 1RPS 設定になっている、問題はなさそうだけど回避もできなさそう
コンソールから個別に設定することはできるけど戻ってしまうらしい
https://gyazo.com/8d32bd8319adf681c762884247a64f47