Arm64 アーキテクチャ (MacBookPro M1) 仮想マシンのインストール k8s1.27.3 バージョンの記録と問題の概要

1. はじめに

ここに画像の説明を挿入

この記事では、macbook pro m1 チップ (arm64 アーキテクチャ) を使用して k8s バージョン 1.27.3 を展開するプロセスと発生した問題を記録します。
同じ問題に遭遇した場合は、ぜひ参考にしてください。
ここに画像の説明を挿入

環境準備:
MacBook Pro M1
VM Ware Fusion
3 arm64 アーキテクチャ 2 コア 4G 50G 仮想マシン

k8s-master 192.168.153.101
k8s-node01 192.168.153.101
k8s-node02 192.168.153.101

k8s 公式 Web サイト: https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/

2. インストール前のセットアップ

2.1 ホスト名の設定

3 つの仮想マシンのホスト名をそれぞれ設定します。

hostnamectl set-hostname k8s-master
hostnamectl set-hostname k8s-node01
hostnamectl set-hostname k8s-mast02

3 つのノードのドメイン名解決を構成する

cat  >> /etc/hosts << EOF
192.168.153.101 k8s-master
192.168.153.102 k8s-node01
192.168.153.103 k8s-mast02
EOF

ノード上で相互にpingping できるかどうかを確認できます。
ここに画像の説明を挿入

2.2 ファイアウォールをオフにする

3 つのノードのファイアウォールをオフにします

# 关闭防火墙
systemctl stop firewalld
# 关闭开机自启
systemctl disable firewalld
# 查看防火墙状态
firewall-cmd --state

2.3 セリナックスを閉じる

#将 SELinux 设置为 permissive 模式(相当于将其禁用)
sudo setenforce 0
sudo sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config

2.4 クローズスワップ

スワップスワップパーティションを無効にする

swapoff -a  # 临时关闭,主机重启后k8s无法自动重启,需要重新关闭swap

sed -i -r '/swap/ s/^/#/' /etc/fstab  # 永久关闭

2.5 iptables によるブリッジされたトラフィックの検査を許可する

cat <<EOT >> /etc/modules-load.d/k8s.conf
overlay
br_netfilter
nf_nat
xt_REDIRECT
xt_owner
iptable_nat
iptable_mangle
iptable_filter
EOT

cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
EOF
modprobe br_netfilter ; modprobe nf_nat ; modprobe xt_REDIRECT ; modprobe xt_owner; modprobe iptable_nat; modprobe iptable_mangle; modprobe iptable_filter

2.6 Dockerのインストール

wget https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo -O /etc/yum.repos.d/docker-ce.repo

yum -y install docker-ce

systemctl enable docker && systemctl start docker

ミラーリングアクセラレーションの構成

sudo mkdir -p /etc/docker

sudo tee /etc/docker/daemon.json <<-'EOF'
{
    
    
  "registry-mirrors": ["https://iedolof4.mirror.aliyuncs.com"],
  "exec-opts": ["native.cgroupdriver=systemd"]
}
EOF

sudo systemctl daemon-reload

sudo systemctl restart docker

docker infoまたはコマンドを使用してdocker version確認します。

3.コンテナランタイムをインストールする

k8s 公式ドキュメント: https://kubernetes.io/zh-cn/docs/setup/production-environment/container-runtimes/containerd
ドキュメント: https://github.com/containerd/containerd/blob/main/docs/getting -started.md

Pod でコンテナを実行するために、Kubernetes は を使用しますcontainer runtime。デフォルトでは、Kubernetes はContainer Runtime Interface(CRI) を使用して、選択したコンテナ ランタイムと対話します。
コンテナー ランタイムを指定しない場合、kubeadm は既知のエンドポイントのリストをスキャンして、インストールされているコンテナー ランタイムを自動的に検出しようとします。コンテナー ランタイムが検出されない場合、kubeadm はエラーをスローします。

v1.24 より前の Kubernetes バージョンには、dockershim と呼ばれる Docker Engine のコンポーネントが直接統合されていました。しかし、バージョン 1.24 以降、Dockershim は Kubernetes プロジェクトから削除されました。したがって、コンテナ ランタイムを手動でデプロイする必要があります

Kubernetes は、次のような多くのコンテナ ランタイムをサポートしていますcontainerdCRI-O

注: インストールする必要があるのは、containerd と cri-docker の 1 つだけです。複数のコンテナー ランタイムが検出された場合、kubeadm はエラーをスローし、使用するコンテナー ランタイムを指定するように求めます。

(すべてのノードで実行する必要があります。)

3.1 コンテナーをインストールする

コンテナードのドキュメント: https://github.com/containerd/containerd/blob/main/docs/getting-started.md

containerd のダウンロード: https://github.com/containerd/containerd/releases
arm64 バージョンのダウンロードに注意してください。

tar Cxzvf /usr/local containerd-1.7.2-linux-arm64.tar.gz
bin/
bin/containerd-shim-runc-v2
bin/containerd-shim
bin/ctr
bin/containerd-shim-runc-v1
bin/containerd
bin/containerd-stress

次に、containerd.serviceそれをダウンロードし/usr/local/lib/systemd/system/containerd.service、containerd をシステム サービスとして登録します: https://raw.githubusercontent.com/containerd/containerd/main/containerd.service
次に、次のコマンドを実行して、containerd サービスを開始します。

systemctl daemon-reload
systemctl enable --now containerd

また、runchttps://github.com/opencontainers/runc/releases をダウンロードしてインストールする必要があります。arm64 バージョンもダウンロードされることに注意してください。

install -m 755 runc.arm64 /usr/local/sbin/runc

CNI plugins最後に、 https://github.com/containernetworking/plugins/releasesをインストールする必要があります。arm64 バージョンを選択します。

$ mkdir -p /opt/cni/bin
$ tar Cxzvf /opt/cni/bin cni-plugins-linux-arm-v1.3.0.tgz
./
./macvlan
./static
./vlan
./portmap
./host-local
./vrf
./bridge
./tuning
./firewall
./host-device
./sbr
./loopback
./dhcp
./ptp
./ipvlan
./bandwidth

containerd のデフォルト構成を生成する/etc/containerd/config.toml

containerd config default > /etc/containerd/config.toml

デフォルトの構成では、使用されるミラー アドレスは ですregistry.k8s.io/pause:3.2。これはダウンロードできないため、aliyun のミラー ソースに置き換える必要があります。

[plugins."io.containerd.grpc.v1.cri"]
  sandbox_image = "registry.k8s.io/pause:3.2"
[plugins."io.containerd.grpc.v1.cri"]
  sandbox_image = "registry.aliyuncs.com/google_containers/pause:3.8"

構成ファイルを更新した後、systemctl restart containerdコマンドを実行してcontainerdを再起動する必要があります。

3.2 cri-dockerのインストール

cri-docker ドキュメント: https://github.com/Mirantis/cri-dockerd
arm64 バージョンのダウンロード: https://github.com/Mirantis/cri-dockerd/releases

tar -zxvf cri-dockerd-0.3.4.arm64.tgz
cd cri-dockerd
vim cri-docker.service
vim cri-docker.socket

2 つのファイルを作成しcri-docker.serviceてファイルし、https://github.com/Mirantis/cri-dockerd/tree/master/packaging/systemd からダウンロードまたはコピーして貼り付けます。cri-docker.socket
ここに画像の説明を挿入

次に、次のコマンドを実行します。

sed -i -e 's,/usr/bin/cri-dockerd,/usr/local/bin/cri-dockerd,' /etc/systemd/system/cri-docker.service
systemctl daemon-reload
systemctl enable cri-docker.service
systemctl enable --now cri-docker.socket

4. k8s クラスターのインストール

4.1 aliyunのkubernetes yumソースを構成する

Ali の yum ソフトウェア ソースを追加します。バージョンbaseurlに注意してください。aarch64

cat > /etc/yum.repos.d/kubernetes.repo << EOF
[kubernetes]
name=Kubernetes
baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-aarch64
enabled=1
gpgcheck=0
repo_gpgcheck=0
gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg
EOF

(すべてのノードで実行する必要があります。)

4.2 kubelet kubeadm kubectl をダウンロードする

sudo yum install -y kubelet kubeadm kubectl --disableexcludes=kubernetes

sudo systemctl enable --now kubelet

(すべてのノードで実行する必要があります。)

4.3 クラスターの初期化 kubeadm init

(k8s-masterノードで実行)

初期化デフォルト構成ファイルを生成します。

kubeadm config print init-defaults > kubeadm.yaml

kubeadm.yaml を変更します。

localAPIEndpoint:
  # 修改为k8s-master节点的IP地址
  advertiseAddress: 192.168.153.101
  bindPort: 6443
nodeRegistration:
  # 设置为Container Runtime 的端点
  criSocket: unix:///var/run/containerd/containerd.sock
  imagePullPolicy: IfNotPresent
  # 修改为k8s-master节点的hostname
  name: k8s-master
  taints: null
...
# 修改为aliyun的镜像地址
imageRepository: registry.cn-hangzhou.aliyuncs.com/google_containers
...

containerd unix:///var/run/containerd/containerd.sock
CRI-O unix:///var/run/crio/crio.sock
Docker エンジン(cri-dockerd を使用) unix:///var/run/cri -dockerd.sock

次に、クラスター初期化コマンドを実行します。

kubeadm init --config=kubeadm.yaml --ignore-preflight-errors=SystemVerification
[root@k8s-master ~]# kubeadm init --config=kubeadm.yaml --ignore-preflight-errors=SystemVerification
[init] Using Kubernetes version: v1.27.3
[preflight] Running pre-flight checks
        [WARNING FileExisting-tc]: tc not found in system path
        [WARNING SystemVerification]: missing optional cgroups: hugetlb
[preflight] Pulling images required for setting up a Kubernetes cluster
[preflight] This might take a minute or two, depending on the speed of your internet connection
[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'
W0705 07:17:49.766204   11729 checks.go:835] detected that the sandbox image "registry.aliyuncs.com/google_containers/pause:3.8" of the container runtime is inconsistent with that used by kubeadm. It is recommended that using "registry.cn-hangzhou.aliyuncs.com/google_containers/pause:3.9" as the CRI sandbox image.
[certs] Using certificateDir folder "/etc/kubernetes/pki"
[certs] Generating "ca" certificate and key
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [k8s-master kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 192.168.153.101]
[certs] Generating "apiserver-kubelet-client" certificate and key
[certs] Generating "front-proxy-ca" certificate and key
[certs] Generating "front-proxy-client" certificate and key
[certs] Generating "etcd/ca" certificate and key
[certs] Generating "etcd/server" certificate and key
[certs] etcd/server serving cert is signed for DNS names [k8s-master localhost] and IPs [192.168.153.101 127.0.0.1 ::1]
[certs] Generating "etcd/peer" certificate and key
[certs] etcd/peer serving cert is signed for DNS names [k8s-master localhost] and IPs [192.168.153.101 127.0.0.1 ::1]
[certs] Generating "etcd/healthcheck-client" certificate and key
[certs] Generating "apiserver-etcd-client" certificate and key
[certs] Generating "sa" key and public key
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "kubelet.conf" kubeconfig file
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[kubeconfig] Writing "scheduler.conf" kubeconfig file
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Starting the kubelet
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
[control-plane] Creating static Pod manifest for "kube-apiserver"
[control-plane] Creating static Pod manifest for "kube-controller-manager"
[control-plane] Creating static Pod manifest for "kube-scheduler"
[etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
[apiclient] All control plane components are healthy after 6.509025 seconds
[upload-config] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config" in namespace kube-system with the configuration for the kubelets in the cluster
[upload-certs] Skipping phase. Please see --upload-certs
[mark-control-plane] Marking the node k8s-master as control-plane by adding the labels: [node-role.kubernetes.io/control-plane node.kubernetes.io/exclude-from-external-load-balancers]
[mark-control-plane] Marking the node k8s-master as control-plane by adding the taints [node-role.kubernetes.io/control-plane:NoSchedule]
[bootstrap-token] Using token: abcdef.0123456789abcdef
[bootstrap-token] Configuring bootstrap tokens, cluster-info ConfigMap, RBAC Roles
[bootstrap-token] Configured RBAC rules to allow Node Bootstrap tokens to get nodes
[bootstrap-token] Configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstrap-token] Configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstrap-token] Configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[bootstrap-token] Creating the "cluster-info" ConfigMap in the "kube-public" namespace
[kubelet-finalize] Updating "/etc/kubernetes/kubelet.conf" to point to a rotatable kubelet client certificate and key
[addons] Applied essential addon: CoreDNS
[addons] Applied essential addon: kube-proxy

Your Kubernetes control-plane has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

Alternatively, if you are the root user, you can run:

  export KUBECONFIG=/etc/kubernetes/admin.conf

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  https://kubernetes.io/docs/concepts/cluster-administration/addons/

Then you can join any number of worker nodes by running the following on each as root:

kubeadm join 192.168.153.101:6443 --token abcdef.0123456789abcdef \
        --discovery-token-ca-cert-hash sha256:d83b1a5a7de6cc8fb54b99a80c9dbbc040d057541f1b2e79f27520f7c1cddfed 
[root@k8s-master ~]# 
[root@k8s-master ~]# 
[root@k8s-master ~]# 
[root@k8s-master ~]# mkdir -p $HOME/.kube
[root@k8s-master ~]# sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
[root@k8s-master ~]# sudo chown $(id -u):$(id -g) $HOME/.kube/config
[root@k8s-master ~]# export KUBECONFIG=/etc/kubernetes/admin.conf
[root@k8s-master ~]# 

4.4 クラスターに参加する kubeadm join

(k8s-node01 ノードと k8s-node02 ノードで実行)

 kubeadm join 192.168.153.101:6443 --token abcdef.0123456789abcdef \
         --discovery-token-ca-cert-hash sha256:d83b1a5a7de6cc8fb54b99a80c9dbbc040d057541f1b2e79f27520f7c1cddfed \
         --cri-socket=unix:///var/run/containerd/containerd.sock

注: コンテナー ランタイムをデプロイする場合は、パラメーターを指定する必要はありません--cri-socket

[root@k8s-node01 ~]# kubeadm join 192.168.153.101:6443 --token abcdef.0123456789abcdef \
>         --discovery-token-ca-cert-hash sha256:d83b1a5a7de6cc8fb54b99a80c9dbbc040d057541f1b2e79f27520f7c1cddfed 
Found multiple CRI endpoints on the host. Please define which one do you wish to use by setting the 'criSocket' field in the kubeadm configuration file: unix:///var/run/containerd/containerd.sock, unix:///var/run/cri-dockerd.sock
To see the stack trace of this error execute with --v=5 or higher

# 由于我部署了两个CRI,所以需要指定
[root@k8s-node01 ~]# kubeadm join 192.168.153.101:6443 --token abcdef.0123456789abcdef \
>         --discovery-token-ca-cert-hash sha256:d83b1a5a7de6cc8fb54b99a80c9dbbc040d057541f1b2e79f27520f7c1cddfed \
>         --cri-socket=unix:///var/run/containerd/containerd.sock
[preflight] Running pre-flight checks
        [WARNING FileExisting-tc]: tc not found in system path
        [WARNING SystemVerification]: missing optional cgroups: hugetlb
[preflight] Reading configuration from the cluster...
[preflight] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Starting the kubelet
[kubelet-start] Waiting for the kubelet to perform the TLS Bootstrap...

This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.

Run 'kubectl get nodes' on the control-plane to see this node join the cluster.

[root@k8s-node01 ~]# 

両方のノードがマスター ノードに追加されましたが、現時点ではクラスターのステータスが準備できていないため、calico を構築するにはネットワークをインストールする必要があります。

[root@k8s-master ~]# kubectl get node
NAME         STATUS     ROLES           AGE     VERSION
k8s-master   NotReady   control-plane   41m     v1.27.3
k8s-node01   NotReady   <none>          2m27s   v1.27.3
k8s-node02   NotReady   <none>          44s     v1.27.3

4.5 ネットワークノードcalicoのインストール

2 つのノードがマスター ノードに参加した後、クラスターはまだ準備完了状態になっていないため、calico ネットワーク コンポーネントをデプロイする必要があります (マスター ノードでのみ次のコマンドを実行します)。

wget https://raw.githubusercontent.com/projectcalico/calico/v3.25.0/manifests/calico.yaml
kubectl apply -f calico.yaml

calico ポッドが実行されるのを待っていると、クラスターが準備完了になります。

[root@k8s-master ~]#  wget https://raw.githubusercontent.com/projectcalico/calico/v3.25.0/manifests/calico.yaml
[root@k8s-master ~]# kubectl get node
NAME         STATUS     ROLES           AGE     VERSION
k8s-master   NotReady   control-plane   41m     v1.27.3
k8s-node01   NotReady   <none>          2m27s   v1.27.3
k8s-node02   NotReady   <none>          44s     v1.27.3
[root@k8s-master ~]# kubectl apply -f calico.yaml
poddisruptionbudget.policy/calico-kube-controllers created
serviceaccount/calico-kube-controllers created
serviceaccount/calico-node created
configmap/calico-config created
customresourcedefinition.apiextensions.k8s.io/bgpconfigurations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/bgppeers.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/blockaffinities.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/caliconodestatuses.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/clusterinformations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/felixconfigurations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/globalnetworkpolicies.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/globalnetworksets.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/hostendpoints.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ipamblocks.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ipamconfigs.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ipamhandles.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ippools.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ipreservations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/kubecontrollersconfigurations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/networkpolicies.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/networksets.crd.projectcalico.org created
clusterrole.rbac.authorization.k8s.io/calico-kube-controllers created
clusterrole.rbac.authorization.k8s.io/calico-node created
clusterrolebinding.rbac.authorization.k8s.io/calico-kube-controllers created
clusterrolebinding.rbac.authorization.k8s.io/calico-node created
daemonset.apps/calico-node created
deployment.apps/calico-kube-controllers created
[root@k8s-master ~]# kubectl get nodes -o wide
NAME         STATUS   ROLES           AGE     VERSION   INTERNAL-IP       EXTERNAL-IP   OS-IMAGE         KERNEL-VERSION            CONTAINER-RUNTIME
k8s-master   Ready    control-plane   43m     v1.27.3   192.168.153.101   <none>        CentOS Linux 8   5.11.12-300.el8.aarch64   containerd://1.7.2
k8s-node01   Ready    <none>          4m39s   v1.27.3   192.168.153.102   <none>        CentOS Linux 8   5.11.12-300.el8.aarch64   containerd://1.7.2
k8s-node02   Ready    <none>          2m56s   v1.27.3   192.168.153.103   <none>        CentOS Linux 8   5.11.12-300.el8.aarch64   containerd://1.7.2
[root@k8s-master ~]# 

問題の結論

質問1 コンテナランタイムが2つデプロイされているため、コマンド実行エラーが発生する

containerd2 つのコンテナ ランタイムをデプロイしたcri-dockerため、コマンドの実行時にエラーが報告されます。これを指定する必要がありますcriSocket

[root@k8s-master ~]# kubeadm reset
[reset] Reading configuration from the cluster...
[reset] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
W0705 01:14:49.210110    8176 reset.go:106] [reset] Unable to fetch the kubeadm-config ConfigMap from cluster: failed to get config map: Get "https://192.168.153.101:6443/api/v1/namespaces/kube-system/configmaps/kubeadm-config?timeout=10s": dial tcp 192.168.153.101:6443: connect: connection refused
Found multiple CRI endpoints on the host. Please define which one do you wish to use by setting the 'criSocket' field in the kubeadm configuration file: unix:///var/run/containerd/containerd.sock, unix:///var/run/cri-dockerd.sock
To see the stack trace of this error execute with --v=5 or higher
kubeadm reset --cri-socket=unix:///var/run/containerd/containerd.sock
 kubeadm join 192.168.153.101:6443 --token abcdef.0123456789abcdef \
         --discovery-token-ca-cert-hash sha256:d83b1a5a7de6cc8fb54b99a80c9dbbc040d057541f1b2e79f27520f7c1cddfed \
         --cri-socket=unix:///var/run/containerd/containerd.sock
kubeadm config images pull --cri-socket=unix:///var/run/cri-dockerd.sock
kubeadm config images pull --config=kubeadm.yaml 

質問 2 kubeadm init クラスターの初期化に失敗しました

kubeadm init コマンドを実行してクラスターを初期化しますが、エラーが発生します。

[root@k8s-master ~]# kubeadm init --config=kubeadm.yaml --ignore-preflight-errors=SystemVerification
[init] Using Kubernetes version: v1.27.3
[preflight] Running pre-flight checks
        [WARNING FileExisting-tc]: tc not found in system path
        [WARNING SystemVerification]: missing optional cgroups: hugetlb
[preflight] Pulling images required for setting up a Kubernetes cluster
[preflight] This might take a minute or two, depending on the speed of your internet connection
[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'
W0704 23:17:25.073160    5627 checks.go:835] detected that the sandbox image "registry.k8s.io/pause:3.8" of the container runtime is inconsistent with that used by kubeadm. It is recommended that using "registry.cn-hangzhou.aliyuncs.com/google_containers/pause:3.9" as the CRI sandbox image.
[certs] Using certificateDir folder "/etc/kubernetes/pki"
[certs] Generating "ca" certificate and key
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [k8s-master kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 192.168.153.101]
[certs] Generating "apiserver-kubelet-client" certificate and key
[certs] Generating "front-proxy-ca" certificate and key
[certs] Generating "front-proxy-client" certificate and key
[certs] Generating "etcd/ca" certificate and key
[certs] Generating "etcd/server" certificate and key
[certs] etcd/server serving cert is signed for DNS names [k8s-master localhost] and IPs [192.168.153.101 127.0.0.1 ::1]
[certs] Generating "etcd/peer" certificate and key
[certs] etcd/peer serving cert is signed for DNS names [k8s-master localhost] and IPs [192.168.153.101 127.0.0.1 ::1]
[certs] Generating "etcd/healthcheck-client" certificate and key
[certs] Generating "apiserver-etcd-client" certificate and key
[certs] Generating "sa" key and public key
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "kubelet.conf" kubeconfig file
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[kubeconfig] Writing "scheduler.conf" kubeconfig file
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Starting the kubelet
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
[control-plane] Creating static Pod manifest for "kube-apiserver"
[control-plane] Creating static Pod manifest for "kube-controller-manager"
[control-plane] Creating static Pod manifest for "kube-scheduler"
[etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
[kubelet-check] Initial timeout of 40s passed.

Unfortunately, an error has occurred:
        timed out waiting for the condition

This error is likely caused by:
        - The kubelet is not running
        - The kubelet is unhealthy due to a misconfiguration of the node in some way (required cgroups disabled)

If you are on a systemd-powered system, you can try to troubleshoot the error with the following commands:
        - 'systemctl status kubelet'
        - 'journalctl -xeu kubelet'

Additionally, a control plane component may have crashed or exited when started by the container runtime.
To troubleshoot, list all containers using your preferred container runtimes CLI.
Here is one example how you may list all running Kubernetes containers by using crictl:
        - 'crictl --runtime-endpoint unix:///var/run/containerd/containerd.sock ps -a | grep kube | grep -v pause'
        Once you have found the failing container, you can inspect its logs with:
        - 'crictl --runtime-endpoint unix:///var/run/containerd/containerd.sock logs CONTAINERID'
error execution phase wait-control-plane: couldn't initialize a Kubernetes cluster
To see the stack trace of this error execute with --v=5 or higher

紆余曲折を経て、イメージがダウンロードできないのが原因ではないかと考え、最終的にcontainerdのログ出力をファイルに
入力して閲覧したところ、イメージがダウンロードできないことが原因であることがわかりました。解決策: containerd 構成ファイルのミラー アドレスを変更します。journalctl -xeu containerd > 1.txtregistry.k8s.io/pause:3.8
ここに画像の説明を挿入

vim /etc/containerd/config.toml
#将镜像修改为阿里源
sandbox_image = "registry.aliyuncs.com/google_containers/pause:3.8"
# 更新后重启containerd服务
systemctl restart containerd

質問 3 kubeadm リセット クラスター リセット

kubeadm initクラスターの初期化が失敗した場合は、kubeadm resetコマンドを使用してクラスターをリセットする必要があります。
2 つのコンテナー ランタイムをデプロイしたため、cri-socket を指定する必要があります。

[root@k8s-master ~]# kubeadm reset
[reset] Reading configuration from the cluster...
[reset] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
W0705 01:14:49.210110    8176 reset.go:106] [reset] Unable to fetch the kubeadm-config ConfigMap from cluster: failed to get config map: Get "https://192.168.153.101:6443/api/v1/namespaces/kube-system/configmaps/kubeadm-config?timeout=10s": dial tcp 192.168.153.101:6443: connect: connection refused
Found multiple CRI endpoints on the host. Please define which one do you wish to use by setting the 'criSocket' field in the kubeadm configuration file: unix:///var/run/containerd/containerd.sock, unix:///var/run/cri-dockerd.sock
To see the stack trace of this error execute with --v=5 or higher

[root@k8s-master ~]# kubeadm reset --cri-socket=unix:///var/run/containerd/containerd.sock
[reset] Reading configuration from the cluster...
[reset] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
W0705 01:17:56.826223    8210 reset.go:106] [reset] Unable to fetch the kubeadm-config ConfigMap from cluster: failed to get config map: Get "https://192.168.153.101:6443/api/v1/namespaces/kube-system/configmaps/kubeadm-config?timeout=10s": dial tcp 192.168.153.101:6443: connect: connection refused
W0705 01:17:56.826877    8210 preflight.go:56] [reset] WARNING: Changes made to this host by 'kubeadm init' or 'kubeadm join' will be reverted.
[reset] Are you sure you want to proceed? [y/N]: y         
[preflight] Running pre-flight checks
W0705 01:18:03.549676    8210 removeetcdmember.go:106] [reset] No kubeadm config, using etcd pod spec to get data directory
[reset] Stopping the kubelet service
[reset] Unmounting mounted directories in "/var/lib/kubelet"
[reset] Deleting contents of directories: [/etc/kubernetes/manifests /var/lib/kubelet /etc/kubernetes/pki]
[reset] Deleting files: [/etc/kubernetes/admin.conf /etc/kubernetes/kubelet.conf /etc/kubernetes/bootstrap-kubelet.conf /etc/kubernetes/controller-manager.conf /etc/kubernetes/scheduler.conf]

The reset process does not clean CNI configuration. To do so, you must remove /etc/cni/net.d

The reset process does not reset or clean up iptables rules or IPVS tables.
If you wish to reset iptables, you must do so manually by using the "iptables" command.

If your cluster was setup to utilize IPVS, run ipvsadm --clear (or similar)
to reset your system's IPVS tables.

The reset process does not clean your kubeconfig files and you must remove them manually.
Please, check the contents of the $HOME/.kube/config file.
[root@k8s-master ~]# 

質問 4 ドメイン名の解決

たとえば、raw.githubusercontent.comドメイン名仮想マシンはそれを解決できません。オンラインのドメイン名解決ツールを使用してドメイン名を解決し、/etc/hostsファイルを構成できます。

[root@k8s-master ~]#  wget https://raw.githubusercontent.com/projectcalico/calico/v3.25.0/manifests/calico.yaml
--2023-07-05 07:42:46--  https://raw.githubusercontent.com/projectcalico/calico/v3.25.0/manifests/calico.yaml
正在解析主机 raw.githubusercontent.com (raw.githubusercontent.com)... 185.199.108.133, 185.199.111.133
正在连接 raw.githubusercontent.com (raw.githubusercontent.com)|185.199.108.133|:443... 已连接。
已发出 HTTP 请求,正在等待回应... 读取文件头错误 (成功。)。
重试中。

--2023-07-05 07:43:34--  (尝试次数: 2)  https://raw.githubusercontent.com/projectcalico/calico/v3.25.0/manifests/calico.yaml
正在连接 raw.githubusercontent.com (raw.githubusercontent.com)|185.199.108.133|:443... ^C
[root@k8s-master ~]# 
cat  >> /etc/hosts << EOF
185.199.108.133 raw.githubusercontent.com
185.199.109.133 raw.githubusercontent.com
185.199.110.133 raw.githubusercontent.com
185.199.111.133 raw.githubusercontent.com
EOF

質問 5 クリティカル

crictl infoCRI (Container Runtime Interface) と互換性のあるコンテナ ランタイムに関する情報を検査および表示するためのコマンド ライン ツールです。CRI は、Kubernetes によって使用されるコンテナー ランタイム インターフェイスであり、コンテナー ランタイムと Kubernetes API サーバー間の通信プロトコルを定義します。

crictlCRI 準拠のランタイムと対話するためのコマンドライン クライアント ツールです。crictl infoコマンドを実行すると、バージョン番号、ランタイムの種類、ソケットのパス、基になる実装など、コンテナー ランタイムに関する詳細情報を取得できます。

このコマンドを使用してcrictl info、コンテナー ランタイムが適切に構成されて実行されていること、および Kubernetes クラスターへの接続が機能していることを確認します。これは、コンテナーのランタイムの問題のトラブルシューティングとデバッグに非常に役立ちます。


[root@k8s-master ~]# crictl info
WARN[0000] runtime connect using default endpoints: [unix:///var/run/dockershim.sock unix:///run/containerd/containerd.sock unix:///run/crio/crio.sock unix:///var/run/cri-dockerd.sock]. As the default settings are now deprecated, you should set the endpoint instead. 
E0705 01:56:46.288578    9440 remote_runtime.go:616] "Status from runtime service failed" err="rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing dial unix /var/run/dockershim.sock: connect: no such file or directory\""
FATA[0000] getting status of runtime: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial unix /var/run/dockershim.sock: connect: no such file or directory" 

[root@k8s-master ~]# sudo cat /etc/crictl.yaml
cat: /etc/crictl.yaml: 没有那个文件或目录
[root@k8s-master ~]# vim /etc/crictl.yaml

crictl.yaml ファイルを手動で作成する

runtime-endpoint: "unix:///run/containerd/containerd.sock"
timeout: 0
debug: false
[root@k8s-master ~]# crictl ps
CONTAINER           IMAGE               CREATED             STATE               NAME                ATTEMPT             POD ID              POD
[root@k8s-master ~]# crictl images
IMAGE                                                                         TAG                 IMAGE ID            SIZE
registry.aliyuncs.com/google_containers/coredns                               v1.10.1             97e04611ad434       14.6MB
registry.cn-hangzhou.aliyuncs.com/google_containers/coredns                   v1.10.1             97e04611ad434       14.6MB
registry.aliyuncs.com/google_containers/etcd                                  3.5.7-0             24bc64e911039       80.7MB
registry.cn-hangzhou.aliyuncs.com/google_containers/etcd                      3.5.7-0             24bc64e911039       80.7MB
registry.aliyuncs.com/google_containers/kube-apiserver                        v1.27.3             39dfb036b0986       30.4MB
registry.cn-hangzhou.aliyuncs.com/google_containers/kube-apiserver            v1.27.3             39dfb036b0986       30.4MB
registry.aliyuncs.com/google_containers/kube-controller-manager               v1.27.3             ab3683b584ae5       28.2MB
registry.cn-hangzhou.aliyuncs.com/google_containers/kube-controller-manager   v1.27.3             ab3683b584ae5       28.2MB
registry.aliyuncs.com/google_containers/kube-proxy                            v1.27.3             fb73e92641fd5       21.4MB
registry.cn-hangzhou.aliyuncs.com/google_containers/kube-proxy                v1.27.3             fb73e92641fd5       21.4MB
registry.aliyuncs.com/google_containers/kube-scheduler                        v1.27.3             bcb9e554eaab6       16.5MB
registry.cn-hangzhou.aliyuncs.com/google_containers/kube-scheduler            v1.27.3             bcb9e554eaab6       16.5MB
registry.aliyuncs.com/google_containers/pause                                 3.9                 829e9de338bd5       268kB
registry.cn-hangzhou.aliyuncs.com/google_containers/pause                     3.9                 829e9de338bd5       268kB
registry.cn-hangzhou.aliyuncs.com/google_containers/kube-apiserver            v1.27.0             a24244f37e14a       30.4MB
registry.cn-hangzhou.aliyuncs.com/google_containers/kube-controller-manager   v1.27.0             9b1932ec3139d       28.2MB
registry.cn-hangzhou.aliyuncs.com/google_containers/kube-proxy                v1.27.0             190160e5595fb       21.4MB
registry.cn-hangzhou.aliyuncs.com/google_containers/kube-scheduler            v1.27.0             09f714df5ecca       16.5MB
[root@k8s-master ~]# 

トラブルシューティングのアイデア

kubelet とcontainerd のログを確認して、イメージのダウンロードが失敗したかどうかを確認します。

systemctl status kubelet
journalctl -xeu kubelet

systemctl status containerd
journalctl -xeu containerd

付録

cri-docker.service

[Unit]
Description=CRI Interface for Docker Application Container Engine
Documentation=https://docs.mirantis.com
After=network-online.target firewalld.service docker.service
Wants=network-online.target
Requires=cri-docker.socket

[Service]
Type=notify
ExecStart=/usr/bin/cri-dockerd --container-runtime-endpoint fd://
ExecReload=/bin/kill -s HUP $MAINPID
TimeoutSec=0
RestartSec=2
Restart=always

# Note that StartLimit* options were moved from "Service" to "Unit" in systemd 229.
# Both the old, and new location are accepted by systemd 229 and up, so using the old location
# to make them work for either version of systemd.
StartLimitBurst=3

# Note that StartLimitInterval was renamed to StartLimitIntervalSec in systemd 230.
# Both the old, and new name are accepted by systemd 230 and up, so using the old name to make
# this option work for either version of systemd.
StartLimitInterval=60s

# Having non-zero Limit*s causes performance problems due to accounting overhead
# in the kernel. We recommend using cgroups to do container-local accounting.
LimitNOFILE=infinity
LimitNPROC=infinity
LimitCORE=infinity

# Comment TasksMax if your systemd version does not support it.
# Only systemd 226 and above support this option.
TasksMax=infinity
Delegate=yes
KillMode=process

[Install]
WantedBy=multi-user.target

cri-docker.socket

[Unit]
Description=CRI Docker Socket for the API
PartOf=cri-docker.service

[Socket]
ListenStream=%t/cri-dockerd.sock
SocketMode=0660
SocketUser=root
SocketGroup=docker

[Install]
WantedBy=sockets.target

おすすめ

転載: blog.csdn.net/DreamsArchitects/article/details/131564732