2021/01/06

今回できたこと

K3sクラスタを、マスタ1台、エージェント1台で構成した。

未解決

今後の作業

現状のK3s入りのRaspberry Pi OSイメージの作成。

エージェントの設定が個別に必要な可能性もあるので、検証必要。

K3sクラスタで簡単な例を用いて動作確認する。

K3sクラスタの他の3台のエージェントノードの設定。

お約束

定例作業

K8s環境の削除

はじめに、K8s環境が動作していることを確認する。

code:shell

pi@worker-rpi3p-1$ ps agxuwww|grep kube

root 411 4.2 7.7 1006648 73676 ? Ssl 09:06 0:21 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --network-plugin=cni --pod-infra-container-image=k8s.gcr.io/pause:3.2

pi 6837 0.0 0.0 3916 500 pts/1 S+ 09:14 0:00 grep --color=auto kube

K8s関連パッケージを削除する。

code:shell

pi@worker-rpi3p-1$ sudo apt-get remove kubelet kubeadm kubectl

パッケージリストを読み込んでいます... 完了

依存関係ツリーを作成しています

状態情報を読み取っています... 完了

以下のパッケージが自動でインストールされましたが、もう必要とされていません:

conntrack cri-tools ebtables kubernetes-cni socat

これを削除するには 'sudo apt autoremove' を利用してください。

以下のパッケージは「削除」されます:

kubeadm kubectl kubelet

アップグレード: 0 個、新規インストール: 0 個、削除: 3 個、保留: 109 個。

この操作後に 157 MB のディスク容量が解放されます。

(データベースを読み込んでいます ... 現在 166099 個のファイルとディレクトリがイン

ストールされています。)

kubeadm (1.19.4-00) を削除しています ...

kubectl (1.19.4-00) を削除しています ...

kubelet (1.19.4-00) を削除しています ...

Warning: The unit file, source configuration file or drop-ins of kubelet.service changed on disk. Run 'systemctl daemon-reload' to reload units.

この時点で、K8s関連プロセスは停止している。

code:shell

pi@worker-rpi3p-1$ ps agxuwww|grep kube

pi 7822 0.0 0.0 3916 532 pts/1 S+ 09:19 0:00 grep --color=auto kube

念のため、再起動を行う。

code:shell

pi@worker-rpi3p-1$ sudo shutdown -r now

master-rpi4の復旧

ここで、Enterを入力しても、同じ状態になるだけであった。

https://gyazo.com/0faaccd97641537b3e0ff4a1243d0578

復旧のために、作業用マシンにUSBカードリーダを接続し、作業を行なった。

パーティションの構成は、以下の通り。

code:shell

$ sudo fdisk -l /dev/sda

Disk /dev/sda: 29.8 GiB, 32010928128 bytes, 62521344 sectors

Disk model: STORAGE DEVICE

Units: sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disklabel type: dos

Disk identifier: 0x0003fdaf

Device Boot Start End Sectors Size Id Type

/dev/sda1 8192 5015625 5007434 2.4G e W95 FAT16 (LBA)

/dev/sda2 5015626 62521343 57505718 27.4G 5 Extended

/dev/sda5 5021696 5087229 65534 32M 83 Linux

/dev/sda6 5087232 5611517 524286 256M c W95 FAT32 (LBA)

/dev/sda7 5611520 62521343 56909824 27.1G 83 Linux

code:shell

$ sudo fsck -y /dev/sda7

fsck from util-linux 2.33.1

e2fsck 1.44.5 (15-Dec-2018)

root: recovering journal

root: clean, 270685/1778880 files, 3703009/7113728 blocks

$ sudo fsck -y /dev/sda1

fsck from util-linux 2.33.1

fsck.fat 4.1 (2017-01-24)

/dev/sda1: 700 files, 75323/78220 clusters

$ sudo fsck -y /dev/sda2

fsck from util-linux 2.33.1

e2fsck 1.44.5 (15-Dec-2018)

fsck.ext2: Attempt to read block from filesystem resulted in short read while trying to open /dev/sda2

Could this be a zero-length partition?

$ sudo fsck -y /dev/sda5

fsck from util-linux 2.33.1

e2fsck 1.44.5 (15-Dec-2018)

SETTINGS: clean, 44/8192 files, 2526/32764 blocks

$ sudo fsck -y /dev/sda6

fsck from util-linux 2.33.1

fsck.fat 4.1 (2017-01-24)

0x41: Dirty bit is set. Fs was not properly unmounted and some data may be corrupt.

Automatically removing dirty bit.

Performing changes.

/dev/sda6: 255 files, 110112/516188 clusters

この手順で、壊れていると思われるファイルシステムをマウントしないようにすると、ブートが可能であった。

具体的な手順は、

code:/etc/fstab

# /dev/sda1 /mnt vfat defaults,rw,uid=1000,gid=1000 0 0

これで、ブートできるようになった。

code:shell

$ sudo fdisk -l /dev/sda

Disk /dev/sda: 28.7 GiB, 30752636928 bytes, 60063744 sectors

Disk model: Ultra Fit

Units: sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disklabel type: dos

Disk identifier: 0x00000000

Device Boot Start End Sectors Size Id Type

/dev/sda1 532480 30425087 29892608 14.3G 83 Linux

$ sudo fsck -y /dev/sda1

fsck from util-linux 2.33.1

e2fsck 1.44.5 (15-Dec-2018)

ext2fs_open2: Bad magic number in super-block

fsck.ext2: Superblock invalid, trying backup blocks...

fsck.ext2: Bad magic number in super-block while trying to open /dev/sda1

The superblock could not be read or does not describe a valid ext2/ext3/ext4

filesystem. If the device is valid and it really contains an ext2/ext3/ext4

filesystem (and not swap or ufs or something else), then the superblock

is corrupt, and you might try running e2fsck with an alternate superblock:

e2fsck -b 8193 <device>

or

e2fsck -b 32768 <device>

$ sudo mount /dev/sda1 /mnt

mount: /mnt: wrong fs type, bad option, bad superblock on /dev/sda1, missing codepage or helper program, or other error.

とりあえず、USBメモリの復旧はあとで行うことにするが、ここにDocker入りのRaspberry Pi OSイメージを保存していたため、再度イメージを作り直す必要がある。

K8sマスターノードでのworkerノード状況の確認

マスターノードで、クラスタの状態を確認したところ、以下のようにワーカーが動いていないことが確認できた。

code:shell

$ kubectl get node

NAME STATUS ROLES AGE VERSION

master-rpi4 Ready master 30d v1.20.1

worker-rpi3p NotReady <none> 30d v1.19.4

worker-rpi4 NotReady <none> 28d v1.20.0

マスターノードのK8s環境の削除

マスターノードでは、以下のようなK8s関連プロセスが動いていた。

code:shell

pi@master-rpi4$ ps agxuwww|grep kube

root 713 19.0 2.2 1084128 87812 ? Ssl 10:09 4:08 /usr/bin/kubel$

t --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/ec/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --network-plugi=cni --pod-infra-container-image=k8s.gcr.io/pause:3.2

root 7278 0.1 0.8 827176 31464 ? Ssl 10:11 0:01 /usr/local/bin$kube-proxy --config=/var/lib/kube-proxy/config.conf --hostname-override=master-$pi4

root 11763 80.1 0.8 830080 33752 ? Ssl 10:30 0:08 kube-scheduler --authentication-kubeconfig=/etc/kubernetes/scheduler.conf --authorization-kubeconfig=/etc/kubernetes/scheduler.conf --bind-address=127.0.0.1 --kubeconfig=/etc/kubernetes/scheduler.conf --leader-elect=true --port=0

pi 13146 0.0 0.0 3916 536 pts/2 S+ 10:30 0:00 grep --color=auto kube

root 24508 7.4 2.0 880976 78964 ? Ssl 10:21 0:42 kube-controller-manager --allocate-node-cidrs=true --authentication-kubeconfig=/etc/kubernetes/controller-manager.conf --authorization-kubeconfig=/etc/kubernetes/controller-manager.conf --bind-address=127.0.0.1 --client-ca-file=/etc/kubernetes/pki/ca.crt--cluster-cidr=10.244.0.0/16 --cluster-name=kubernetes --cluster-signing-cert-file=/etc/kubernetes/pki/ca.crt --cluster-signing-key-file=/etc/kubernetes/pki/ca.key --controllers=*,bootstrapsigner,tokencleaner --kubeconfig=/etc/kubernetes/controller-manager.conf --leader-elect=true --node-cidr-mask-size=24 --port=0 --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt --root-ca-file=/etc/kubernetes/pki/ca.crt --service-account-private-key-file=/etc/kubernetes/pki/sa.key --service-cluster-ip-range=10.96.0.0/12 --use-service-account-credentials=true

K8s環境のパッケージを削除する。

code:shell

pi@master-rpi4$ sudo apt-get remove kubelet kubeadm kubectl

パッケージリストを読み込んでいます... 完了

依存関係ツリーを作成しています

状態情報を読み取っています... 完了

以下のパッケージが自動でインストールされましたが、もう必要とされていません:

conntrack cri-tools ebtables kubernetes-cni libexiv2-14 libgfortran3

libgmime-2.6-0 socat

これを削除するには 'sudo apt autoremove' を利用してください。

以下のパッケージは「削除」されます:

kubeadm kubectl kubelet

アップグレード: 0 個、新規インストール: 0 個、削除: 3 個、保留: 40 個。

この操作後に 158 MB のディスク容量が解放されます。

(データベースを読み込んでいます ... 現在 189853 個のファイルとディレクトリがイン

ストールされています。)

kubeadm (1.20.1-00) を削除しています ...

kubectl (1.20.1-00) を削除しています ...

kubelet (1.20.1-00) を削除しています ...

Warning: The unit file, source configuration file or drop-ins of kubelet.service changed on disk. Run 'systemctl daemon-reload' to reload units.

この状態でも、K8s関連プロセスは動作していたため、再起動を行う。

code:shell

pi@master-rpi4$ sudo shutdown -r now

再起動後は、K8s関連プロセスは無くなった。

code:shell

pi@master-rpi4$ ps agxuwww|grep kube

pi 957 0.0 0.0 3916 500 pts/1 S+ 10:34 0:00 grep --color=auto kube

K3sマスターノードの構築

インストール用スクリプトを利用して、K3s環境をインストールする。

code:shell

Created symlink /etc/systemd/system/multi-user.target.wants/k3s.service → /etc/systemd/system/k3s.service.

インストール後、以下のようなpodが動作していることが確認できる。

code:shell

pi@master-rpi4$ sudo kubectl get pods --all-namespaces

NAMESPACE NAME READY STATUS RESTARTS AGE

kube-system helm-install-traefik-fzkrd 0/1 Completed 3 36m

kube-system metrics-server-86cbb8457f-v6hzd 1/1 Running 6 36m

kube-system local-path-provisioner-7c458769fb-hsmmw 1/1 Running 13 36m

kube-system svclb-traefik-s7jp8 2/2 Running 2 23m

kube-system coredns-854c77959c-2b4gv 1/1 Running 2 36m

kube-system traefik-6f9cbd9bd4-25pk9 1/1 Running 1 23m

クラスタの状況は、以下のように確認できる。

code:shell

pi@master-rpi4$ sudo kubectl get nodes

NAME STATUS ROLES AGE VERSION

master-rpi4 Ready control-plane,master 37m v1.20.0+k3s2

code:shell

pi@master-rpi4$ sudo k3s check-config

Verifying binaries in /var/lib/rancher/k3s/data/c8ca2ef57aa8ef0951f3d6c5aafbe235

4ef69054c8011f5859283a9d282e4b75/bin:

- sha256sum: good

- links: good

System:

- /usr/sbin iptables v1.8.2 (nf_tables): should be older than v1.8.0 or in legacy mode (fail)

- swap: disabled

- routes: ok

Limits:

- /proc/sys/kernel/keys/root_maxkeys: 1000000

info: reading kernel config from /proc/config.gz ...

Generally Necessary:

- CONFIG_NAMESPACES: enabled

- CONFIG_NET_NS: enabled

- CONFIG_PID_NS: enabled

- CONFIG_IPC_NS: enabled

- CONFIG_UTS_NS: enabled

- CONFIG_CGROUPS: enabled

- CONFIG_CGROUP_CPUACCT: enabled

- CONFIG_CGROUP_DEVICE: enabled

- CONFIG_CGROUP_FREEZER: enabled

- CONFIG_CGROUP_SCHED: enabled

- CONFIG_CPUSETS: enabled

- CONFIG_MEMCG: enabled

- CONFIG_KEYS: enabled

- CONFIG_VETH: enabled (as module)

- CONFIG_BRIDGE: enabled (as module)

- CONFIG_BRIDGE_NETFILTER: enabled (as module)

- CONFIG_IP_NF_FILTER: enabled (as module)

- CONFIG_IP_NF_TARGET_MASQUERADE: enabled (as module)

- CONFIG_NETFILTER_XT_MATCH_ADDRTYPE: enabled (as module)

- CONFIG_NETFILTER_XT_MATCH_CONNTRACK: enabled (as module)

- CONFIG_NETFILTER_XT_MATCH_IPVS: enabled (as module)

- CONFIG_IP_NF_NAT: enabled (as module)

- CONFIG_NF_NAT: enabled (as module)

- CONFIG_POSIX_MQUEUE: enabled

Optional Features:

- CONFIG_USER_NS: enabled

- CONFIG_SECCOMP: enabled

- CONFIG_CGROUP_PIDS: enabled

- CONFIG_BLK_CGROUP: enabled

- CONFIG_BLK_DEV_THROTTLING: enabled

- CONFIG_CGROUP_PERF: enabled

- CONFIG_CGROUP_HUGETLB: missing

- CONFIG_NET_CLS_CGROUP: enabled (as module)

- CONFIG_CGROUP_NET_PRIO: enabled

- CONFIG_CFS_BANDWIDTH: enabled

- CONFIG_FAIR_GROUP_SCHED: enabled

- CONFIG_RT_GROUP_SCHED: missing

- CONFIG_IP_NF_TARGET_REDIRECT: enabled (as module)

- CONFIG_IP_SET: enabled (as module)

- CONFIG_IP_VS: enabled (as module)

- CONFIG_IP_VS_NFCT: enabled

- CONFIG_IP_VS_PROTO_TCP: enabled

- CONFIG_IP_VS_PROTO_UDP: enabled

- CONFIG_IP_VS_RR: enabled (as module)

- CONFIG_EXT4_FS: enabled

- CONFIG_EXT4_FS_POSIX_ACL: enabled

- CONFIG_EXT4_FS_SECURITY: enabled

- Network Drivers:

- "overlay":

- CONFIG_VXLAN: enabled (as module)

Optional (for encrypted networks):

- CONFIG_CRYPTO: enabled

- CONFIG_CRYPTO_AEAD: enabled (as module)

- CONFIG_CRYPTO_GCM: enabled (as module)

- CONFIG_CRYPTO_SEQIV: enabled (as module)

- CONFIG_CRYPTO_GHASH: enabled (as module)

- CONFIG_XFRM: enabled

- CONFIG_XFRM_USER: enabled

- CONFIG_XFRM_ALGO: enabled

- CONFIG_INET_ESP: enabled (as module)

- CONFIG_INET_XFRM_MODE_TRANSPORT: missing

- Storage Drivers:

- "overlay":

- CONFIG_OVERLAY_FS: enabled (as module)

STATUS: 1 (fail)

念のため、ファイアウォール系の設定を確認するが、動いていないようである。

code:shell

pi@master-rpi4$ systemctl status firewalld

Unit firewalld.service could not be found.

pi@master-rpi4$ systemctl status iptables

Unit iptables.service could not be found.

code:shell

pi@master-rpi4$ iptables --version

iptables v1.8.2 (nf_tables)

code:shell

pi@master-rpi4$ sudo update-alternatives --config iptables

alternative iptables (/usr/sbin/iptables を提供) には 2 個の選択肢があります。

選択肢 パス 優先度 状態

------------------------------------------------------------

* 0 /usr/sbin/iptables-nft 20 自動モード

1 /usr/sbin/iptables-legacy 10 手動モード

2 /usr/sbin/iptables-nft 20 手動モード

update-alternatives: /usr/sbin/iptables (iptables) を提供するためにマニュアルモードで /usr/sbin/iptables-legacy を使います

code:shell

pi@master-rpi4$ ps agxuwwww|grep kube

pi 5765 0.0 0.0 3916 508 pts/1 S+ 11:30 0:00 grep --color=auto kube

pi@master-rpi4$ ps agxuwwww|grep k3s

root 628 69.8 11.2 901444 439908 ? Ssl 11:01 4:38 /usr/local/bin/k3s server

root 1639 0.0 0.2 802812 8920 ? Sl 11:02 0:00 /var/lib/rancher/k3s/data/c8ca2ef57aa8ef0951f3d6c5aafbe2354ef69054c8011f5859283a9d282e4b75/bin/containerd-shim-runc-v2 -namespace k8s.io -id 125336ca7c86d12f6f06ed6a78792c13f0c5eba8fbe62bdac41225dc1d576338 -address /run/k3s/containerd/containerd.sock

root 1677 0.0 0.2 802812 9164 ? Sl 11:02 0:00 /var/lib/rancher/k3s/data/c8ca2ef57aa8ef0951f3d6c5aafbe2354ef69054c8011f5859283a9d282e4b75/bin/containerd-shim-runc-v2 -namespace k8s.io -id 765f8729d19b4d95ee2aaf8cd8c357f1092f012c6469bf74fd252d2d264eabd2 -address /run/k3s/containerd/containerd.sock

root 1722 0.0 0.2 802812 8772 ? Sl 11:02 0:00 /var/lib/rancher/k3s/data/c8ca2ef57aa8ef0951f3d6c5aafbe2354ef69054c8011f5859283a9d282e4b75/bin/containerd-shim-runc-v2 -namespace k8s.io -id defb42a7582e2390a38a6b68228e89afdc1c1cbeef86fd9cb37cb6008c93523a -address /run/k3s/containerd/containerd.sock

root 2525 0.0 0.2 803068 9036 ? Sl 11:02 0:00 /var/lib/rancher/k3s/data/c8ca2ef57aa8ef0951f3d6c5aafbe2354ef69054c8011f5859283a9d282e4b75/bin/containerd-shim-runc-v2 -namespace k8s.io -id b5cb2f72ec25172b36371262b98d84e089370c6a54144a462e6e35ce3ff430f7 -address /run/k3s/containerd/containerd.sock

root 2610 0.0 0.2 803068 9288 ? Sl 11:02 0:00 /var/lib/rancher/k3s/data/c8ca2ef57aa8ef0951f3d6c5aafbe2354ef69054c8011f5859283a9d282e4b75/bin/containerd-shim-runc-v2 -namespace k8s.io -id a2f03fd4f011b80826c7b4b09f5f498a3e68362a1d342398e11e980d6dfa6f08 -address /run/k3s/containerd/containerd.sock

pi 5069 0.0 0.0 3916 504 pts/3 S+ 11:08 0:00 grep --color=auto k3s

K3sエージェントノードの構築

code:shell

0+k3s2/sha256sum-arm.txt

Created symlink /etc/systemd/system/multi-user.target.wants/k3s-agent.service →

/etc/systemd/system/k3s-agent.service.

マスターノードから確認すると、以下のようにクラスタが構成されていることがわかる。

code:shell

pi@master-rpi4$ sudo kubectl get nodes

NAME STATUS ROLES AGE VERSION

master-rpi4 Ready control-plane,master 121m v1.20.0+k3s2

worker-rpi4-1 Ready <none> 119s v1.20.0+k3s2

K3sマスターノードでのkubectl getのTimeoutに関する問題

一度こうなると、これ以降ずっとタイムアウトして応答が返らない状態である。

code:shell

pi@master-rpi4$ sudo kubectl get pods --all-namespaces

Error from server (Timeout): the server was unable to return a response in the time allotted, but may still be processing the request (get pods)

pi@master-rpi4$ sudo kubectl get nodes

Unable to connect to the server: net/http: request canceled (Client.Timeout exceeded while awaiting headers)

K3sを以下のように再起動すると復旧するが、原因がよくわからない。

code:shell

pi@master-rpi4$ sudo systemctl restart k3s

再起動後にpodsの状態を確認すると、特に問題なく動作しているようである。

code:shell

pi@master-rpi4$ sudo kubectl get pods --all-namespaces

NAMESPACE NAME READY STATUS RESTARTS AGE

kube-system helm-install-traefik-fzkrd 0/1 Completed 3 163m

kube-system svclb-traefik-tfp2c 2/2 Running 0 43m

kube-system coredns-854c77959c-2b4gv 1/1 Running 2 163m

kube-system local-path-provisioner-7c458769fb-hsmmw 1/1 Running 46 163m

kube-system traefik-6f9cbd9bd4-25pk9 1/1 Running 1 150m

kube-system metrics-server-86cbb8457f-v6hzd 1/1 Running 6 163m

kube-system svclb-traefik-s7jp8 2/2 Running 2 150m

ログは、以下のようになっている。

code:shell

● k3s.service - Lightweight Kubernetes

Loaded: loaded (/etc/systemd/system/k3s.service; enabled; vendor preset: enabled)

Active: active (running) since Wed 2021-01-06 13:15:14 JST; 15min ago

Process: 20035 ExecStartPre=/sbin/modprobe br_netfilter (code=exited, status=0/SUCCESS)

Process: 20036 ExecStartPre=/sbin/modprobe overlay (code=exited, status=0/SUCCESS)

Main PID: 20037 (k3s-server)

Tasks: 103

Memory: 559.4M

CGroup: /system.slice/k3s.service

├─ 1866 /var/lib/rancher/k3s/data/c8ca2ef57aa8ef0951f3d6c5aafbe2354ef69054c8011f5859283a9d282e4b75/bin/containerd-shim-runc-v2 -namespace k8s.io -id 752f9086f743887f3040ed351236fc1de9

d907a081def3ac3b8817fffd75db0f -address /run/k3s/containerd/containerd.sock

├─ 1876 /var/lib/rancher/k3s/data/c8ca2ef57aa8ef0951f3d6c5aafbe2354ef69054c8011f5859283a9d282e4b75/bin/containerd-shim-runc-v2 -namespace k8s.io -id f0b8fb285ba24e502c4f3d4377bd6f3dec0da69b6036b723ec7c12002aabeb4a -address /run/k3s/containerd/containerd.sock

├─ 1901 /var/lib/rancher/k3s/data/c8ca2ef57aa8ef0951f3d6c5aafbe2354ef69054c8011f5859283a9d282e4b75/bin/containerd-shim-runc-v2 -namespace k8s.io -id 0093abb2377c8e9207333c31dc59cc70ee33750a2d14e9fffd0fdb699b36e413 -address /run/k3s/containerd/containerd.sock

├─ 1924 /var/lib/rancher/k3s/data/c8ca2ef57aa8ef0951f3d6c5aafbe2354ef69054c8011f5859283a9d282e4b75/bin/containerd-shim-runc-v2 -namespace k8s.io -id 41f416cbcb3843ebd1023f19c81e818119407c35512b4f068cb076ab6ccab065 -address /run/k3s/containerd/containerd.sock

├─ 1983 /pause

├─ 1990 /pause

├─ 1996 /pause

├─ 1999 /pause

├─ 2043 /var/lib/rancher/k3s/data/c8ca2ef57aa8ef0951f3d6c5aafbe2354ef69054c8011f5859283a9d282e4b75/bin/containerd-shim-runc-v2 -namespace k8s.io -id b76b5ecb2788913f87399890c9571ac9c7739e98899800c5448b759696b0b384 -address /run/k3s/containerd/containerd.sock

├─ 2074 /pause

├─ 2125 /metrics-server

├─ 2200 /coredns -conf /etc/coredns/Corefile

├─ 2252 /traefik --configfile=/config/traefik.toml

├─ 2302 /bin/sh /usr/bin/entry

├─ 2409 /bin/sh /usr/bin/entry

├─20037 /usr/local/bin/k3s server

└─20142 containerd

ログの解釈を含めて、原因究明は後日行うこととする。