KubernetesのヘルスチェックのAPIエンドポイントを試す。
といっても提供されているエンドポイントをcurl叩けばよいだけ。
現在は3つのエンドポイントが提供されているが、1つは非推奨とのこと。
- healthz (非推奨)
- livez
- readyz
livezとreadyzの違いは、具体的な内訳までは書かれてないけど、liveness probeとreadyness probeの違いと同じと考えてよさそうで、livez=生きている・readyz=サービス提供可能と解釈してよさそう。(内部でクラスタやアプリが生きてるだけでよいか、外部からのアクセスに反応できるか、的な？)
kubectlを使ったヘルスチェック
$ kubectl get --raw='/readyz' ok
冗長オプションもあり、?verboseを付加すると情報量が増える。
ドキュメントによると「人間がチェックするために使用するもの」とのこと。
$ kubectl get --raw='/readyz?verbose' [+]ping ok [+]log ok [+]etcd ok [+]etcd-readiness ok [+]informer-sync ok [+]poststarthook/start-kube-apiserver-admission-initializer ok [+]poststarthook/generic-apiserver-start-informers ok [+]poststarthook/priority-and-fairness-config-consumer ok [+]poststarthook/priority-and-fairness-filter ok [+]poststarthook/storage-object-count-tracker-hook ok [+]poststarthook/start-apiextensions-informers ok [+]poststarthook/start-apiextensions-controllers ok [+]poststarthook/crd-informer-synced ok [+]poststarthook/start-service-ip-repair-controllers ok [+]poststarthook/rbac/bootstrap-roles ok [+]poststarthook/scheduling/bootstrap-system-priority-classes ok [+]poststarthook/priority-and-fairness-config-producer ok [+]poststarthook/start-system-namespaces-controller ok [+]poststarthook/bootstrap-controller ok [+]poststarthook/start-cluster-authentication-info-controller ok [+]poststarthook/start-kube-apiserver-identity-lease-controller ok [+]poststarthook/start-deprecated-kube-apiserver-identity-lease-garbage-collector ok [+]poststarthook/start-kube-apiserver-identity-lease-garbage-collector ok [+]poststarthook/start-legacy-token-tracking-controller ok [+]poststarthook/aggregator-reload-proxy-client-cert ok [+]poststarthook/start-kube-aggregator-informers ok [+]poststarthook/apiservice-registration-controller ok [+]poststarthook/apiservice-status-available-controller ok [+]poststarthook/kube-apiserver-autoregistration ok [+]autoregister-completion ok [+]poststarthook/apiservice-openapi-controller ok [+]poststarthook/apiservice-openapiv3-controller ok [+]poststarthook/apiservice-discovery-controller ok [+]shutdown ok readyz check passed
curlでヘルスチェック
APIサーバー(通常kubectl cluster-infoとかで確認できる接続先サーバー)の/livezか/readyzにアクセスする。
以下readyzの場合
$ curl -k 'https://192.168.0.131:6443/readyz' ok
こんな感じでkubectl get --raw='/readyzと同じ応答が返る。
kubectlの場合と同じく、?verboseを付与すれば情報量が増える。
認証が必要な場合
外部の監視ツールなどからHTTPSアクセスで普通に使えるはずだけど、Kubernetesディストリビューションによっては認証が必要な場合があるっぽい。
たとえばK3sのクラスター(v1.28.4)だと認証エラーになった。
$ curl -k 'https://192.168.0.75:6443/readyz'
{
"kind": "Status",
"apiVersion": "v1",
"metadata": {},
"status": "Failure",
"message": "Unauthorized",
"reason": "Unauthorized",
"code": 401
}
この場合はdefault Service Accountのトークンを使った認証が簡単で、kubectl create tokenで生成できる。
$ export K8S_TOKEN=$(kubectl create token default -n default) $ curl -k -H "Authorization: Bearer $K8S_TOKEN" 'https://192.168.0.75:6443/readyz' ok
kubectl create token以外では、トークン用のSecretリソースを作成してもOK
まず以下のリソースを作成して
apiVersion: v1 kind: Secret metadata: name: default-token annotations: kubernetes.io/service-account.name: default type: kubernetes.io/service-account-token
で
$ SECRET_TOKEN=$(kubectl get secret default-token -o jsonpath='{.data.token}' | base64 --decode)
$ curl -k -H "Authorization: Bearer $SECRET_TOKEN" 'https://192.168.0.75:6443/readyz'
ok
といった感じ。
ただ、どういう状況の時にOKではなくなるのかが不明…
CoreDNSを落としたり、workerノードをシャットダウンしたりしても特に問題なかった。
情報をお持ちの方、ぜひ教えてください。
環境
- 192.168.0.131 (kubeadm構築): 1.28.2
- 192.168.0.75 (k3s構築): 1.28.4
