winds.from.oz 技術メモ

Gentooでkubernetesのトラブルシューティング

トラブルシューティングのログ

machine-idがないエラーが出る

$ sudo journalctl -r --since today | less
 8月 02 00:48:56 k3s-prd-agent-g k3s[364]: W0802 00:48:56.104196     364 info.go:53] Couldn't collect info from any of the files in "/etc/machine-id,/var/lib/dbus/machine-id"
 8月 02 00:48:56 k3s-prd-agent-g k3s[364]: E0802 00:48:56.103437     364 info.go:119] Failed to get system UUID: open /etc/machine-id: no such file or directory

machine-idのファイルが存在するか確認する。

sudo ls -l /etc/machine-id /var/lib/dbus/machine-id
ls: '/etc/machine-id' にアクセスできません: そのようなファイルやディレクトリはありません
lrwxrwxrwx 1 root root 15  3月 18 21:43 /var/lib/dbus/machine-id -> /etc/machine-id

ファイルが無かったので作成する。

sudo systemd-machine-id-setup

メトリクスサーバが起動していなかった

検証でサーバを増やす際にddコピーでサーバを増やしており、k3sサーバとk3sエージェントの整合性が崩れ、正常に動作していなかったケースを調査して直したのであまり参考にはならない。 一応、記録として残す。

E0706 00:24:50.413023    2860 resource_quota_controller.go:413] unable to retrieve the complete list of server APIs: metrics.k8s.io/v1beta1: the server is currently unable to handle the request
W0706 00:24:50.434573    2860 garbagecollector.go:747] failed to discover some groups: map[metrics.k8s.io/v1beta1:the server is currently unable to handle the request]
E0706 00:25:20.435843    2860 resource_quota_controller.go:413] unable to retrieve the complete list of server APIs: metrics.k8s.io/v1beta1: the server is currently unable to handle the request
W0706 00:25:20.469495    2860 garbagecollector.go:747] failed to discover some groups: map[metrics.k8s.io/v1beta1:the server is currently unable to handle the request]"

れは、kube-systemという名前のネームスペースで動作するPodをリストアップする。 Metrics Serverは通常、このネームスペースで実行される。

kubectl -n kube-system get pods

次の状態だった。 metrics-server-668d979685-mlzxn がメトリクスサーバだが、ステータスが CrashLoopBackOff になっていた。

root@k3s-prd-server /v/log# kubectl -n kube-system get pods
NAME                                      READY   STATUS             RESTARTS           AGE
metrics-server-668d979685-mlzxn           0/1     CrashLoopBackOff   35068 (4d7h ago)   286d
local-path-provisioner-7b7dc8d6f5-bq77w   0/1     CrashLoopBackOff   35915 (4d7h ago)   286d
coredns-b96499967-sqmmb                   0/1     Running            41351 (4d7h ago)   286d

podsのログを調べる。

kubectl -n kube-system logs metrics-server-668d979685-mlzxn

どうも別のホストで動かしているが、正常に動作していない

root@k3s-prd-server /v/log# kubectl -n kube-system logs metrics-server-668d979685-mlzxn
Error from server: Get "https://10.10.254.58:10250/containerLogs/kube-system/metrics-server-668d979685-mlzxn/metrics-server": proxy error from 127.0.0.1:6443 while dialing 10.10.254.58:10250, code 503: 503 Service Unavailable

この別のサーバでのメトリクスサーバを動作させる。

本来だとメトリクスサーバが動いている側(k3sではエージェントと呼ぶ側でコンテナが起動している側)でログを確認する

time="2023-07-07T00:07:34+09:00" level=error msg="token CA hash does not match th
e Cluster CA certificate hash:ハッシュ値 != ハッシュ値"

サーバ側とエージェント側で登録しているハッシュ値が異なる。

サーバ側でトークンを確認

cat /var/lib/rancher/k3s/server/node-token

エージェント側で再度k3sをインストール

curl -sfL https://get.k3s.io | K3S_TOKEN=[server_token] K3S_URL=https://[server_external_ip]:6443 sh -

k3sのエージェント側からk3sサーバに通信が走り、k3sサーバ側に登録された。 メトリクスサーバが起動し始めた。

kubectl -n kube-system get pods
NAME                                      READY   STATUS        RESTARTS           AGE
metrics-server-668d979685-mlzxn           0/1     Terminating   35068 (5d7h ago)   287d
local-path-provisioner-7b7dc8d6f5-bq77w   0/1     Terminating   35915 (5d7h ago)   287d
coredns-b96499967-sqmmb                   0/1     Terminating   41351 (5d7h ago)   287d
local-path-provisioner-7b7dc8d6f5-xfzpn   1/1     Running       0                  112s
coredns-b96499967-nr44p                   1/1     Running       0                  112s
metrics-server-668d979685-zpkrg           1/1     Running       0                  112s

terraformでapply時、途中でキャンセルすると既にリソースがある状態になる

terraformでstateファイルと実際が異なる

リソースを削除して良い状態なら消してしまった方が早い

下記のようなエラーが出た場合

module.resource_pack_server.kubernetes_service_v1.svc: Creating...
module.resource_pack_server.kubernetes_deployment_v1.this: Creating...
╷
│ Error: Failed to create deployment: deployments.apps "common-resource-pack" already exists
│
│   with module.resource_pack_server.kubernetes_deployment_v1.this,
│   on ../../modules/nginx_static/main.tf line 42, in resource "kubernetes_deployment_v1" "this":
│   42: resource "kubernetes_deployment_v1" "this" {
│
╵
╷
│ Error: services "common-resource-pack" already exists
│
│   with module.resource_pack_server.kubernetes_service_v1.svc,
│   on ../../modules/nginx_static/main.tf line 100, in resource "kubernetes_service_v1" "svc":
│  100: resource "kubernetes_service_v1" "svc" {
  • エラー文の “deployments.apps "common-resource-pack" already exists” から、既に存在している Kubernetes リソースの種類 (Deployment) と名前 (common-resource-pack) を読み取ります。同様に “services "common-resource-pack" already exists” は Service が重複していることを示します。
  • Namespace が不明なときは kubectl get deployment common-resource-pack -A や kubectl get service common-resource-pack -A でどこにあるか確認します。Terraform 側で namespace を指定しているな ら、その名前空間を優先的にチェックします。
  • 対象が確定したら kubectl delete deployment common-resource-pack -n と kubectl delete service common-resource-pack -n を実行します。ファイル経由で削除したい場合は kubectl delete -f <manifest.yaml> のように -f オプションを使います。
  • オプションを詳しく見たいときは kubectl delete –help や kubectl options を参考にし、–grace-period や –wait など必要に応じて追加します。
  • 削除後に kubectl get で存在しないことを確認し、再度 terraform apply -var-file=env/common.tfvars を実行して整合性を取ります。