DUICUO

現在の場所： ホーム > 記事 > kube-vip を使用した高可用性 Kubernetes クラスターの構築

kube-vip を使用した高可用性 Kubernetes クラスターの構築

[[406052]]

kube-vip は、コントロール プレーン ノードにネイティブの Kubernetes 高可用性ロード バランサーを提供できるため、クラスターの高可用性を実現するために HAProxy と Keepalived を外部で構成する必要がなくなります。

kube-vipは、内部および外部のKubernetesクラスタに高可用性と負荷分散を提供するオープンソースプロジェクトです。VMwareのTanzuプロジェクトでは、kube-vipがvSphereデプロイメントで使用されているHAProxyロードバランサの代替として採用されています。この記事では、まずKubernetesコントロールプレーンにおける高可用性と負荷分散のためにkube-vipをどのように活用できるかを理解します。

特徴

Kube-Vip はもともと Kubernetes コントロール プレーンに HA ソリューションを提供するために作成されましたが、時間の経過とともに進化し、同じ機能を Kubernetes LoadBalancer タイプのサービスに組み込むようになりました。

  • VIP アドレスは IPv4 または IPv6 のいずれかになります。
  • ARP（レイヤー2）またはBGP（レイヤー3）を使用した制御プレーン
  • リーダーシップ選出またはRaftコントロールプレーンを使用する
  • kubeadm を使用した HA コントロール プレーン (静的 Pod)
  • K3s およびその他 (DaemonSets) を使用したコントロール プレーン HA
  • ARPリーダー選出を使用したサービスロードバランサ（レイヤー2）
  • BGP経由で複数のノードを持つサービスロードバランサーを使用する
  • 各名前空間またはサービス LoadBalancer のグローバル アドレス プール
  • サービス LoadBalancer アドレスは、UPNP 経由でゲートウェイに公開されます。

HA プロキシと kube-vip HA クラスター

以前は、プライベート環境でKubernetesクラスターを作成する場合、マルチコントロールプレーンクラスターを構築するためにハードウェア/ソフトウェアロードバランサーを用意する必要がありました。多くの場合、この機能を実現するためにHAProxy + Keepalivedを使用していました。通常は、ロードバランサー用に2台の仮想マシンを作成し、VIPを割り当て、そのVIPを使用してロードバランサーにサービスを提供することで、トラフィックをバックエンドの特定のKubernetesコントローラープレーンノードにリダイレクトしていました。

次に、kube-vip を使用するとどうなるかを見てみましょう。

kube-vip は、コントロールプレーンノード上で静的ポッドを介して実行できます。これらのポッドは ARP 通信を介して各ノード上の他のホストを識別するため、各ノードの IP アドレスを hosts ファイルに設定する必要があります。ロードバランサーの設定には、Metal LB と同様に BGP または ARP を選択できます。今回は BGP サービスを使用しておらず、簡単なテストを行うだけなので、ARP と静的ポッドを使用します。

kube-vip アーキテクチャ

kube-vip は、VIP/負荷分散ソリューションの一部として高可用性やネットワーク機能を提供するためのさまざまな機能設計オプションを提供します。

クラスタ

kube-vip は、高可用性を実現するために、マルチノードまたはマルチモジュールクラスタを構築します。ARPモードでは、仮想IPを継承し、クラスタ内のロードバランサのリーダーとなるリーダーが選出されます。BGPモードでは、すべてのノードがVIPアドレスを共有します。

ARPまたはレイヤー2を使用する場合、リーダー選出が使用されます。もちろん、Raftクラスタ技術も使用できますが、特にクラスタ内で実行する場合、この方法はリーダー選出に大きく置き換えられています。

仮想IP

クラスタ内のリーダーはVIPを割り当て、設定で宣言された選択されたインターフェースにバインドします。リーダーが変更されると、まずVIPが取り消されます。または、障害が発生した場合は、次に選出されたリーダーによってVIPが直接割り当てられます。

VIPがホスト間で移動されると、そのVIPを使用しているホストは、ARPの有効期限が切れるまで（通常30秒）、新しいVIP <-> MACアドレスマッピングが取得されるまで、以前のVIP <-> MACアドレスマッピングを保持します。これは、フリーARPブロードキャストを使用することで最適化できます。

ARP

kube-vip は、フリー ARP (オプション) をブロードキャストするように構成できます。これにより、通常、VIP <-> MAC アドレス マッピングが変更されたことがすべてのローカルホストに直ちに通知されます。

以下に示すように、ARP ブロードキャストを受信すると、フェイルオーバーは通常数秒以内に完了します。

  1.  192.168.0.75からの64バイト: icmp_seq=146 ttl=64 time =0.258 ms
  2.  192.168.0.75からの64バイト: icmp_seq=147 ttl=64 time =0.240 ms
  3.  192.168.0.70からの92 バイト: リダイレクトホスト (新しいアドレス: 192.168.0.75)
  4.  Vr HL TOS Len ID FlgオフTTL Pro cks Src Dst
  5.  4 5 00 0054 bc98 0 0000 3f 01 3d16 192.168.0.95 192.168.0.75 
  6.  
  7.  icmp_seq 148のリクエストタイムアウト
  8. 192.168.0.70からの92 バイト: リダイレクトホスト (新しいアドレス: 192.168.0.75)
  9.  Vr HL TOS Len ID FlgオフTTL Pro cks Src Dst
  10.  4 5 00 0054 75ff 0 0000 3f 01 83af 192.168.0.95 192.168.0.75 
  11.  
  12.  icmp_seq 149のリクエストタイムアウト
  13. 192.168.0.70からの92 バイト: リダイレクトホスト (新しいアドレス: 192.168.0.75)
  14.  Vr HL TOS Len ID FlgオフTTL Pro cks Src Dst
  15.  4 5 00 0054 2890 0 0000 3f 01 d11e 192.168.0.95 192.168.0.75 
  16.  
  17.  icmp_seq 150のリクエストタイムアウト
  18. 192.168.0.75からの64バイト: icmp_seq=151 ttl=64 time =0.245 ms

kube-vipを使用する

次に、kube-vipを使って高可用性Kubernetesクラスターを構築します。まず、6つのノードを準備します。

  • 3つのコントロールプレーンノード
  • 3 つのワーカーノード

まず、kubeadm、kubelet、kubectl、コンテナ ランタイム (ここでは containerd を使用しています) などの関連する依存関係をホスト マシンにインストールします。

kube-vip Dockerイメージを取得し、/etc/kuberentes/manifestsに静的ポッドYAMLマニフェストファイルを設定します。これにより、Kubernetesは各コントロールプレーンノードにkube-vipポッドを自動的にデプロイできるようになります。

  1.  # VIPアドレスを設定する
  2. エクスポート VIP=192.168.0.100
  3. エクスポート INTERFACE=eth0
  4.  ctr イメージ プル docker.io/plndr/kube-vip:0.3.1
  5.  ctr 実行--rm --net-host docker.io/plndr/kube-vip:0.3.1 vip \  
  6.  /kube-vip マニフェストポッド \
  7.  --インターフェース $INTERFACE \  
  8.  --vip $VIP \  
  9.  --コントロールプレーン \  
  10.  --サービス 
  11.  --arp \  
  12.  --leaderElection | /etc/kubernetes/manifests/kube-vip.yaml を編集する 

次に、以下のように kubeadm を設定します。

  1.  cat > ~/init_kubelet.yaml <<EOF
  2.  APIバージョン: kubeadm.k8s.io/v1beta2
  3. 種類: InitConfiguration
  4. ブートストラップトークン:
  5.  - トークン: "9a08jv.c0izixklcxtmnze7"  
  6. 説明: 「kubeadm ブートストラップ トークン」  
  7.  ttl: "24時間"  
  8. ノード登録:
  9.  criSocket: "/var/run/containerd/containerd.sock"  
  10.  ---  
  11.  APIバージョン: kubeadm.k8s.io/v1beta2
  12. 種類: ClusterConfiguration
  13. コントロールプレーンエンドポイント: "192.168.0.100:6443"  
  14.  ---  
  15.  apiバージョン: kubelet.config.k8s.io/v1beta1
  16. 種類: KubeletConfiguration
  17.  cgroupドライバー: "systemd"  
  18. カーネルデフォルトを保護: true  
  19. 終了
  20. kubeadm init --config init_kubelet.yaml --upload-certs  

次に、CNI をインストールします。たとえば、Cilium を使用することを選択します。

  1.  curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bash
  2.  helm リポジトリに ciliumを追加しますhttps://helm.cilium.io/
  3.  helm install cilium cilium/cilium --version 1.9.4 \  
  4.  --namespace kube-system  

最初のコントロールプレーンノードの準備ができたら、他のノードがクラスターに参加できるようにします。他のコントロールプレーンノードについては、次のコマンドを実行します。

  1.  kubeadm join 192.168.0.100:6443 --token hash.hash\  
  2.  --discovery-token-ca-cert-hash sha256:ハッシュ \  
  3.  --control-plane --certificate-key キー 

ワーカーノードの場合は、次のようなコマンドを実行します。

  1.  kubeadm join 192.168.0.100:6443 --token hash.hash\  
  2.  --discovery-token-ca-cert-hash sha256:ハッシュ 

プロセスが完了すると、クラスターを起動できます。 

  1. # kubectl get node -o ワイド
  2. 名前ステータス 役割 年齢 バージョン 内部IP 外部IP OSイメージ カーネルバージョン コンテナランタイム
  3. k8s-master-0 コントロールプレーン、マスター 121m v1.20.2 192.168.0.201 <なし> Ubuntu 20.04.2 LTS 5.4.0-45-generic containerd://1.4.3 が準備完了
  4. k8s-master-1 コントロールプレーン、マスター 114m v1.20.2 192.168.0.202 <なし> Ubuntu 20.04.2 LTS 5.4.0-45-generic containerd://1.4.3 が準備完了
  5. k8s-master-2 コントロールプレーン、マスター 113m v1.20.2 192.168.0.203 <なし> Ubuntu 20.04.2 LTS 5.4.0-45-generic containerd://1.4.3 が準備完了
  6. k8s-worker-0 準備完了 <なし> 114m v1.20.2 192.168.0.204 <なし> Ubuntu 20.04.2 LTS 5.4.0-45-generic containerd://1.4.3
  7.  k8s-worker-1 準備完了 <なし> 114m v1.20.2 192.168.0.205 <なし> Ubuntu 20.04.2 LTS 5.4.0-45-generic containerd://1.4.3
  8.  k8s-worker-2 準備完了 <なし> 112m v1.20.2 192.168.0.206 <なし> Ubuntu 20.04.2 LTS 5.4.0-45-generic containerd://1.4.3

これで、コントロール プレーンのエンドポイントが 192.168.0.100 であり、他に追加のノードがないことがわかります。これは非常に便利です。

参考ドキュメント: https://inductor.medium.com/say-good-bye-to-haproxy-and-keepalived-with-kube-vip-on-your-ha-k8s-control-plane-bb7237eca9fc

ラベル

関連するおすすめ記事

ランダムにおすすめされた記事

人気のタグ