GKE ingress NEGが動かないときに確認すること
この記事について
GKE with GCLBでアプリケーションを組む場合はNEG(Network Endpoint Group)の利用が推奨されています。ただ、このNEGの導入がすんなりといかない場合、初期状態だとログなどが特にでないためデバッグがかなり困難です。
そこで自身が過去に直面したり想定されうることをベースに確認事項や対応を備忘録的に記します。
確認すること & 対応 集
何はともあれGUIから確認
下記のURLからNEG一覧を確認できます。
NEGの名前だったり使用リソースをぽちぽちしていくと色んな情報が見れるので、もしそこで原因に気がつくことができればめでたしめでたし。
経験上原因のほとんどがヘルスチェックが通っていないことだったりするので要確認。デフォルトではログを出力しない設定になっていますが、必要に応じて有効化することもできます。
ヘルスチェックの確認画面
何はともあれ公式docを確認
NEGリソースは存在していますか？
上記のGCPのGUIやコマンド(kubectl get svcneg)でNEGリソースがあるかどうか確認できます。
もし存在していなければServiceなどmanifestに誤りがないか確認しましょう。
routing対象のPodにReadinessProbeが設定されていますか？
ちゃんとReadinessProbeが設定されていないと動かないです。
またhttpGet形式にしてください。
routing対象のPodのReadinessProbeにCustom Headerが設定されていませんか？
これが地味にハマりポイント。
公式docにある通りCustom Headerが設定されているHealthcheckのパスが強制的に/とされてしまいます。
注: 有効な Kubernetes readiness Probe では、readinessProbe.httpGet で複数の HTTP ヘッダーを設定できます。readinessProbe.httpGet.httpHeaders で Host ヘッダー以外も指定されている場合、ロードバランサのヘルスチェック パラメータは、readiness Probe から推定される値ではなく、デフォルト値に設定されます。この制限は、ヘルスチェックが Host ヘッダーの設定のみをサポートしているために存在します。
ReadinessProbeではCustom Headerを使用しないようにしましょう。
Healthcheckエンドポイントはちゃんと機能しますか？
設定したHealthcheckエンドポイントがちゃんと機能するかどうかを確認してください。
LivenessProbeで同じpathを設定 & Podがrestartしていなければ機能しているとみなしてok。
NEGなしの状態で動いていましたか？
NEGなしの状態でもちゃんと動いていなければIngress->Service-> Podの繋ぎこみ設定が悪いはずです。
port番号の設定ミスやtypoがないか確認しましょう。
sidecarを使ってますか？
sidecarを使っている場合は+αで設定が
Discussion