安定性と拡張性を強化したk8s高可用性ソリューション「クラウドネイティブ」の解説と実践運用

1. 概要

高可用性ソリューションに関する私の以前の記事やその他のオンライン資料では、基本的にほとんどが Keepalived VIP ソリューションを使用していますが、このソリューションは最適ではありません。より優れた高可用性ソリューションも存在しますが、これについては以下で詳しく説明します。

2. 建築

3. 展開を開始する

（１）ノード情報

（２）事前準備（全ノード）

1) ホストを構成する

 192.168.182.110 ローカル-168-182-110
 192.168.182.111 ローカル-168-182-111
 192.168.182.112 ローカル-168-182-112
 192.168.182.113 ローカル-168-182-113
 192.168.182.130 ローカル-168-182-130

2) 相互信頼を構成する

 # Enterキーを押し続ける
sshキー生成

ssh-copy-id -i ~/.ssh/id_rsa.pub root@local-168-182-110
 ssh-copy-id -i ~/.ssh/id_rsa.pub root@local-168-182-111
 ssh-copy-id -i ~/.ssh/id_rsa.pub root@local-168-182-112
 ssh-copy-id -i ~/.ssh/id_rsa.pub root@local-168-182-113
 ssh-copy-id -i ~/.ssh/id_rsa.pub root@local-168-182-130

3) 時刻同期

 yum インストール chrony -y
 systemctl 開始 chronyd
 systemctl は chronyd を有効にします
systemctl ステータス chronyd
クロニクソース

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

 systemctl 停止 ファイアウォール
systemctl ファイアウォールを無効にする

5) SELinuxを無効にする

 # 一時閉店
強制0を設定する
# 永久に無効にする
sed -i 's/^SELINUX=enforcing$/SELINUX=disabled/' /etc/selinux/config

6) スワップをオフにする

 # 一時的に閉鎖します。スワップを閉じるのは主にパフォーマンス上の考慮のためです
スワップオフ -a
 # このコマンドを使用して、スワップが閉じられているかどうかを確認できます
無料
# 永久に閉店
sed -ri 's/.*swap.*/#&/' /etc/fstab

7) bridge-nf-call-iptablesを設定する

猫 <<EOF | sudo tee /etc/modules-load.d/k8s.conf
かぶせる
br_netfilter
終了

sudo modprobeオーバーレイ
sudo modprobe br_netfilter

 # 必要な sysctl パラメータを設定します。再起動後も変更されません。
猫 <<EOF | sudo tee /etc/sysctl.d/k8s.conf
 net.bridge.bridge-nf-call-iptables = 1
 net.bridge.bridge-nf-call-ip6tables = 1
ネット.ipv4.ip_forward = 1
終了

# 再起動せずにsysctlパラメータを適用する
sudo sysctl --system

（３）Dockerコンテナをインストールする（全ノード）

 # yumソースを設定する
yum.repos.d をコピーします。 mkdir を戻します。 mv CentOS-Linux-* バックアップ/
 # セントロス7
 wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo

 # yum-config-manager設定ツールをインストールする
yum -y yum-utilsをインストールします
# yumソースを設定する
yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo
 # docker-ceバージョンをインストール
yum インストール -y docker-ce
 # 起動してシステムを自動的に起動するように設定する
# 起動時に自動的に開始するように設定し、サービスをすぐに開始します --now: サービスをすぐに開始します
systemctl enable --now docker

 # バージョン番号を確認する
docker --バージョン
# バージョンの詳細を表示
docker バージョン

# Docker イメージソース設定
# /etc/docker/daemon.json ファイルを変更します。このファイルが存在しない場合は作成します。
 # docker cgroup ドライバー systemd を構成する
# 次のコンテンツを追加した後、Docker サービスを再起動します。
 cat >/etc/docker/daemon.json<<EOF
 {
 "レジストリミラー": ["http://hub-mirror.c.163.com"],
 "exec-opts": ["native.cgroupdriver=systemd"]
 }
終了
＃ 負荷
systemctl dockerを再起動します

＃ チェック
systemctl ステータス docker

(4) k8s yumソースを構成する（全ノード）

 cat > /etc/yum.repos.d/kubernetes.repo << EOF
 [k8s]
名前=k8s
有効=1
 gpgcheck=0
ベースURL=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/
終了

（5）kubeadm、kubelet、kubectlのインストールを開始する（全ノード）

 # すべてのバージョンを検索します。ここではバージョン 1.23.x を選択します。
 yum --showduplicates リスト kubelet

 #disableexcludes=kubernetes: このkubernetes以外のすべてのリポジトリを無効にします
yum インストール -y kubelet-1.23.6 kubeadm-1.23.6 kubectl-1.23.6 --disableexcludes=kubernetes

 # 起動時に自動的に開始するように設定し、サービスをすぐに開始します --now: サービスをすぐに開始します
systemctl enable --now kubelet

 # ステータスを確認します。サービスステータスを確認するには、しばらくお待ちください。起動は少し遅くなります。
 systemctl ステータス kubelet

 # バージョンを確認する
kubectl バージョン
yum 情報 kubeadm

（6）kubeadmを使用してクラスタを初期化する（最初のマスターノード）

インストールを早くするために、事前にイメージをダウンロードしておくのがベストです。

 docker pull registry.aliyuncs.com/google_containers/kube-apiserver:v1.23.6
 docker pull registry.aliyuncs.com/google_containers/kube-controller-manager:v1.23.6
 docker pull registry.aliyuncs.com/google_containers/kube-scheduler:v1.23.6
 docker pull registry.aliyuncs.com/google_containers/kube-proxy:v1.23.6
 docker pull registry.aliyuncs.com/google_containers/pause:3.6
 docker pull registry.aliyuncs.com/google_containers/etcd:3.5.1-0
 docker pull registry.aliyuncs.com/google_containers/coredns:v1.8.6

クラスタの初期化

 kubeadm 初期化 \
 --apiserver-advertise-address=192.168.182.110 \
 --イメージリポジトリ registry.aliyuncs.com/google_containers \
 --kubernetes-バージョン v1.23.6 \
 --コントロールプレーンエンドポイント=192.168.182.110 \
 --service-cidr=10.1.0.0/16 \
 --pod-network-cidr=10.244.0.0/16 \
 --v=5
 # –image-repository 文字列: イメージを取得する場所を指定するために使用されます (バージョン 1.13 でのみ使用可能)。デフォルト値は k8s.gcr.io です。国内イメージアドレスとして指定します: registry.aliyuncs.com/google_containers
 # –kubernetes-version 文字列: kubenets のバージョン番号を指定します。デフォルト値は stable-1 で、最新のバージョン番号が https://dl.k8s.io/release/stable-1.txt からダウンロードされます。ネットワーク リクエストをスキップするには、固定バージョン (v1.22.1) として指定できます。
 # –apiserver-advertise-address は、クラスター内の他のノードと通信するために使用するマスターのインターフェースを指定します。マスターに複数のインターフェースがある場合は、それらを明示的に指定することをお勧めします。指定しない場合、kubeadm はデフォルト ゲートウェイを持つインターフェースを自動的に選択します。ここでの IP はマスター ノードの IP です。必ず変更してください。
 # –pod-network-cidr は Pod ネットワークの範囲を指定します。 Kubernetes は複数のネットワーク ソリューションをサポートしており、ネットワーク ソリューションごとに –pod-network-cidr に対する独自の要件があります。ここでは、フランネル ネットワーク ソリューションを使用するため、この CIDR に設定する必要があるため、10.244.0.0/16 に設定されています。
 # --control-plane-endpoint cluster-endpoint は、この IP にマップされたカスタム DNS 名です。ここで、ホスト マッピングは 127.0.0.1 cluster-endpoint に構成されています。これにより、--control-plane-endpoint=cluster-endpoint を kubeadm init に渡し、同じ DNS 名を kubeadm join に渡すことができます。高可用性シナリオでは、後で cluster-endpoint を変更してロード バランサーのアドレスを指すようにすることができます。 

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

ノード情報の表示

 kubectl ノードを取得する

ノードが NotReady 状態であることが判明しました。ログを確認すると、CNI ネットワーク プラグインがインストールされていないことがわかります。次に、Calico ネットワーク プラグインのインストールを開始します。もちろん、他のネットワーク プラグインを選択することもできます。

（7）Calicoネットワークプラグインをインストールする

 https://docs.projectcalico.org/manifests/calico.yaml を取得します。
 kubectl を適用 -f calico.yaml

 ＃ チェック
kubectl get all -n kube-system|grep calico

 # カリコポッドが正常になるまで待ってから、ノードのステータスを確認します
kubectl ポッドを取得 -A
 kubectl ノードを取得する

（8）IPVSを構成する（全ノード）

1) ip_vs関連のカーネルモジュールをロードする

 modprobe --ip_vs
 modprobe --ip_vs_sh
 modprobe --ip_vs_rr
 modprobe --ip_vs_wrr

すべてのノードは ipvs が有効になっていることを確認します。

 lsmod |grep ip_vs

2) ipvsadmツールをインストールする

 yum インストール ipset ipvsadm -y

3) kube-proxy設定ファイルを編集し、モードをipvsに変更します。

 kubectl edit configmap -n kube-system kube-proxy

4) kube-proxyを再起動します

 # 最初に確認
kubectl get ポッド -n kube-system | grep kube-proxy
 # もう一度削除して自動的に表示されるようにする
kubectl get ポッド -n kube-system | grep kube-proxy |awk '{system("kubectl delete pod "$1" -n kube-system")}'
 # もう一度確認
kubectl get ポッド -n kube-system | grep kube-proxy

（9）マスターノードがクラスターに参加する

【質問】

新しいコントロール プレーン インスタンスをホストするための 1 つ以上の条件が満たされていません。安定した controlPlaneEndpoint アドレスを持たないクラスターに新しいコントロール プレーン インスタンスを追加できません

[解決策] 次の構成を追加します。

 # コントロールプレーンエンドポイント: 192.192.168.110
 kubectl 編集 cm kubeadm-config -n kube-system

次のコマンドを実行して、マスターノードをクラスターに追加します。

 # 実行コマンドを取得するには、最初のマスターノードで次のコマンドを実行します。
 # 証明書の有効期限が切れている場合は、次のコマンドを使用して新しい証明書を生成し、アップロードできます。証明書キーはここに印刷され、後で使用されます。
 CERT_KEY=`kubeadm init フェーズの upload-certs --upload-certs|tail -1`

 # --ttl=0 は、生成されたトークンが期限切れにならないことを意味します。 --ttl パラメータが含まれていない場合、デフォルトの有効期間は 24 時間です。 24 時間以内であれば、労働者を無制限に追加できます。
 echo `kubeadm token create --print-join-command --ttl=0` " --control-plane --certificate-key $CERT_KEY --v=5"

 # 上記のコマンドを取得し、追加するノードで実行します

# --control-plane フラグは、kubeadm join に新しいコントロール プレーンを作成するように指示します。マスターに参加するにはこのマークを追加する必要があります
# --certificate-key ... により、コントロール プレーン証明書がクラスター内の kubeadm-certs シークレットからダウンロードされ、指定されたキーを使用して復号化されます。ここでの値は、上記のコマンド (kubeadm init phase upload-certs --upload-certs) によって印刷されたキーです。

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

ネットワークプラグインが自動的にインストールされたら、ノードのステータスを確認します。

 kubectl ノードを取得する

（10）マスターノードを自分のAPIサーバーを指すように変更する

1) 設定を変更する

 /etc/kubernetes をコピーします
# /etc/kubernetes/admin.conf を変更し、/etc/kubernetes/kubelet.conf ファイル内のサーバー IP を 127.0.0.1 に変更します
vi /etc/kubernetes/admin.conf
 vi /etc/kubernetes/kubelet.conf

 # 設定を上書きする
/etc/kubernetes/admin.conf をコピーします。~/.kube/config

2) 古い証明書を削除し、新しい証明書を生成します

 /etc/kubernetes/pki に移動します

# まずバックアップ
mv apiserver.key apiserver.key.bak
 mv apiserver.crt apiserver.crt.bak

 # 次のコマンドを使用して、3つのマスターノードでそれぞれ生成して実行します。
 kubeadm init フェーズの証明書 apiserver --apiserver-advertise-address 192.168.182.110 --apiserver-cert-extra-sans "127.0.0.1,10.1.0.1"

 kubeadm init フェーズの証明書 apiserver --apiserver-advertise-address 192.168.182.113 --apiserver-cert-extra-sans "127.0.0.1,10.1.0.1"

 kubeadm init フェーズの証明書 apiserver --apiserver-advertise-address 192.168.182.130 --apiserver-cert-extra-sans "127.0.0.1,10.1.0.1"
 # --apiserver-cert-extra-sans "127.0.0.1": ノード検証証明書フェーズ中にエラーが報告されないようにこれを設定します。

3) apiserverを変更する

 kubectl -n kube-system を編集 cm kubeadm-config -o yaml

4) kube-prxoy設定を変更する

 kubectl edit cm kube-proxy -oyaml -n kube-system

再起動

 kubectl delete pod -n kube-system `kubectl get pods -n kube-system|grep kube-proxy|awk '{print $1}'`

5) dockerとkubeletを再起動します

 systemctl 再起動 docker kubelet

（11）ノードにnginxをインストールする

ここではnginxの4層プロキシを使用します

 mv /etc/yum.repos.d/CentOS-Base.repo /etc/yum.repos.d/CentOS-Base.repo.backup
 wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo
 yum メイクキャッシュ
yum で epel-release をインストールします
yum -y nginxをインストール
yum -y nginx-all-modules.noarch をインストールします

nginx を設定し、nginx.conf に次の設定を追加します。

 stream { #4層プロキシ機能を実現する
 アップストリームkube_apiserver { #クラスターを定義します。kube_apiserverはクラスター名で、自分で定義できます。
 least_conn;# デフォルトのスケジューリング戦略はラウンドロビンです。ラウンドロビンでは、サーバーがダウンすると自動的に削除されます。
 サーバー local-168-182-110:6443 max_fails=3 fail_timeout=30s; #クラスタグループは3つのサーバk8s apiserverで構成されています
 サーバー local-168-182-113:6443 max_fails=3 fail_timeout=30s;
 サーバー local-168-182-130:6443 max_fails=3 fail_timeout=30s;
 }
 server { #サービスを定義する
 127.0.0.1:6443 をリッスンします。 #リッスンするポート
 proxy_pass kube_apiserver; #コールクラスター
 proxy_connect_timeout 10秒; # 接続タイムアウト
 proxy_timeout 300秒; #ポート保持時間
 }
 }

（12）ノードがクラスタに参加する

 # 実行コマンドを取得するには、最初のマスターノードで次のコマンドを実行します。
 # 証明書の有効期限が切れている場合は、次のコマンドを使用して新しい証明書を生成し、アップロードできます。証明書キーはここに印刷され、後で使用されます。
 CERT_KEY=`kubeadm init フェーズの upload-certs --upload-certs|tail -1`

 # --ttl=0 は、生成されたトークンが期限切れにならないことを意味します。 --ttl パラメータが含まれていない場合、デフォルトの有効期間は 24 時間です。 24 時間以内であれば、労働者を無制限に追加できます。
 echo `kubeadm token create --print-join-command --ttl=0` " --certificate-key $CERT_KEY --v=5"
 # 以下は例です:
 kubeadm は 127.0.0.1:6443 に参加します --token esczfh.6ckynzi6wfj8jhnk --discovery-token-ca-cert-hash sha256:bc8fb85184ed235b88afdba38f0a17976d353abb10d0739d25df452745d1eed8 --certificate-key a126867ad4d91721f157660df77cdea7862ebda8371280c3025c4cc45c23b85f --v=5

/etc/kubernetes/kubelet.conf設定を変更する

再起動

 systemctl kubelet を再起動します

ネットワークプラグインが自動的にインストールされたら、ノードのステータスを確認します。

 kubectl ノードを取得する
kubectl ポッドを取得 -A

（13）アンインストール

 kubeadm リセット
rm -rf /etc/kubernetes/*
 rm -fr ~/.kube
 rm -fr /var/lib/etcd

4. 高可用性障害モードテスト

（１）マスターノード障害シミュレーション（１つのマスター障害）

 # 192.168.182.110 をシャットダウン
対決 -h 今
# 他のマスターノードのノードステータスを確認する
kubectl ノードを取得する

【結論】上図に示すように、マスターノードがハングしてもクラスターには影響しません。

（２）マスターノード障害シミュレーション（２つのマスター障害）

 # シャットダウン 192.168.182.113
対決 -h 今
# 他のマスターノードのノードステータスを確認する
kubectl ノードを取得する

[結論] 上図に示すように、2 つのマスター ノードがハングすると、クラスター全体が使用できなくなります。前述したように、3 つのマスター ノードのうち、ハングアップできるマスター ノードは 1 つだけなので、ここでは詳細には説明しません。