Kube-vip を使用して高可用性の Kubernetes クラスターを構築する (フル バージョン)

[[422792]]

前回のコースのクラスターはシングルマスター クラスターであり、実稼働環境にはリスクが大きすぎます。可用性の高いクラスターを作成することは非常に重要です。ここでの高可用性は、主に kube-apiserver、etcd、kube-controller-manager、kube-scheduler などのコントロール パネルを指します。 kube-controller-manager および kube-scheduler コンポーネントは可用性が高く、Kubernetes クラスター自体によって実装されます。複数のコンポーネントがある場合、サービスを提供するリーダーとして 1 つが自動的に選択されるため、高可用性を手動で実装する必要はありません。 apiserver と etcd は、高可用性クラスターを手動で構築する必要があります。一般的な haproxy + keepalived アーキテクチャや、プロキシ実装に nginx を使用するなど、高可用性アーキテクチャは多数あります。

環境の準備

4 つのノード、すべて Centos 7.6 システム、カーネル バージョン: 3.10.0-1062.4.1.el7.x86_64、各ノードにホスト情報を追加します。

 ➜ ~ cat /etc/hosts
 192.168.31.10 api.k8s。ローカル# VIP
 192.168.31.31 マスター1
 192.168.31.32 マスター2
 192.168.31.33 マスター3
 192.168.31.100 ノード1

このうち、192.168.31.10 は VIP であり、ドメイン名 api.k8s.local がマッピングに使用されます。

• ノードのホスト名には標準の DNS 命名規則を使用する必要があります。また、デフォルトの localhost ホスト名は使用しないでください。さまざまなエラーが発生します。 Kubernetes プロジェクトでは、マシン名と Etcd に保存されるすべての API オブジェクトに標準の DNS 命名規則 (RFC 1123) を使用する必要があります。ホスト名を変更するには、コマンド hostnamectl set-hostname node1 を使用できます。

ファイアウォールを無効にします。

 ➜ ~ systemctl でファイアウォールを停止します
➜ ~ systemctl ファイアウォールを無効にする

SELINUXを無効にする:

 ➜ ~ 0 を設定する
➜ ~ cat /etc/selinux/config
 SELINUX=無効

カーネル IPv4 転送を有効にするには br_netfilter モジュールをロードする必要があるため、モジュールをロードします。

 ➜ ~ modprobe br_netfilter

/etc/sysctl.d/k8s.conf ファイルを作成し、次の内容を追加します。

 net.bridge.bridge-nf-call-ip6tables = 1
 net.bridge.bridge-nf-call-iptables = 1
ネット.ipv4.ip_forward = 1

変更を有効にするには、次のコマンドを実行します。

 ➜ ~ sysctl -p /etc/sysctl.d/k8s.conf

ipvsをインストールします:

 ➜ ~ cat > /etc/sysconfig/modules/ipvs.modules <<EOF
 #!/bin/bash
 modprobe --ip_vs  
 modprobe --ip_vs_rr  
 modprobe --ip_vs_wrr  
 modprobe --ip_vs_sh  
 modprobe --nf_conntrack_ipv4  
終了
➜ ~ chmod 755 /etc/sysconfig/modules/ipvs.modules && bash /etc/sysconfig/modules/ipvs.modules && lsmod | grep -e ip_vs -e nf_conntrack_ipv4

上記のスクリプトによって作成された /etc/sysconfig/modules/ipvs.modules ファイルにより、ノードの再起動後に必要なモジュールが自動的にロードされるようになります。 lsmod を実行します | grep -e ip_vs -e nf_conntrack_ipv4 コマンドを実行して、必要なカーネル モジュールが正しくロードされているかどうかを確認します。

次に、各ノードに ipset パッケージがインストールされていることを確認する必要があります。

 ➜ ~ yum インストール ipset

ipvs のプロキシ ルールを表示するには、管理ツール ipvsadm をインストールするのが最適です。

 ➜ ~ yum インストール ipvsadm

サーバー時間を同期する

➜ ~ yum インストール chrony -y
 ➜ ~ systemctl chronyd を有効にする
➜ ~ systemctl chronyd を起動します
➜ ~ chronyc ソース
210 ソース数= 4
 MS名/IPアドレス 階層 ポーリング 到達 最終受信最終サンプル
=======================================================================
 ^+ sv1.ggsrv.de 2 6 17 32 -823us[-1128us] +/- 98ms
 ^- montreal.ca.logiplex.net 2 6 17 32 -17ms[ -17ms] +/- 179ms
 ^- ntp6.flashdance.cx 2 6 17 32 -32ms[ -32ms] +/- 161ms
 ^* 119.28.183.184 2 6 33 32 +661us[ +357us] +/- 38ms
 ➜ ~日付 
 2021年8月31日火曜日 14:36:14 CST

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

 ➜ ~ スワップオフ -a

/etc/fstab ファイルを変更し、SWAP の自動マウントをコメント アウトし、free -m を使用してスワップが無効になっていることを確認します。 swappiness パラメータを調整するには、/etc/sysctl.d/k8s.conf を変更し、次の行を追加します。

 vm.swappiness=0

変更を有効にするには、sysctl -p /etc/sysctl.d/k8s.conf を実行します。

Containerdをインストールする

コンテナ ランタイム containerd の基本的な使い方を学習したので、各ノードに Containerd をインストールしましょう。

containerd は runc を呼び出す必要があるため、最初に runc もインストールする必要があります。ただし、containerd は関連する依存関係を含む圧縮パッケージ cri-containerd-cni-${VERSION}.${OS}-${ARCH}.tar.gz を提供しており、これを直接インストールに使用できます。まず、リリース ページから圧縮パッケージの最新バージョン (現在はバージョン 1.5.5) をダウンロードします。

 ➜ ~ wget https://github.com/containerd/containerd/releases/download/v1.5.5/cri-containerd-cni-1.5.5-linux-amd64.tar.gz
 # 制限がある場合は、ダウンロードを高速化するために次のURLに置き換えることもできます
# wget https://download.fastgit.org/containerd/containerd/releases/download/v1.5.5/cri-containerd-cni-1.5.5-linux-amd64.tar.gz

圧縮パッケージをシステムのさまざまなディレクトリに直接解凍します。

 ➜ ~ tar -C / -xzf cri-containerd-cni-1.5.5-linux-amd64.tar.gz

次に、~/.bashrc ファイルの PATH 環境変数に /usr/local/bin と /usr/local/sbin を追加します。

エクスポート PATH=$PATH:/usr/ローカル/bin:/usr/ローカル/sbin

次に、次のコマンドを実行して、すぐに有効にします。

 ➜ ~ ソース ~/.bashrc

containerd のデフォルトの設定ファイルは /etc/containerd/config.toml です。次のコマンドを実行すると、デフォルト構成を生成できます。

 ➜ ~ mkdir -p /etc/containerd
 ➜ ~ containerd 設定デフォルト> /etc/containerd/config.toml

systemd を init システムとして使用する Linux ディストリビューションの場合、コンテナの cgroup ドライバーとして systemd を使用すると、リソースが不足しているときにノードがより安定するため、containerd の cgroup ドライバーを systemd に設定することをお勧めします。

以前に生成された設定ファイル /etc/containerd/config.toml を変更し、plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options 設定ブロックの下で SystemdCgroup を true に設定します。

 [プラグイン。 「io.containerd.grpc.v1.cri」 .containerd.runtimes.runc]
  ...
  [プラグイン。 「io.containerd.grpc.v1.cri」 .containerd.runtimes.runc.options]
    SystemdCgroup = true  
    ....

次に、イメージ リポジトリのアクセラレータを構成します。 cri 構成ブロックの下の registry 構成ブロックで registry.mirrors を構成する必要があります。

 [プラグイン。 [[io.containerd.grpc.v1.cri] ]
  ...
  # サンドボックスイメージ = "k8s.gcr.io/pause:3.5"  
  サンドボックスイメージ = "registry.aliyuncs.com/k8sxio/pause:3.5"  
  ...
  [プラグイン。 ["io.containerd.grpc.v1.cri" .レジストリ]
    [プラグイン。 ["io.containerd.grpc.v1.cri" .registry.mirrors]
      [プラグイン。 "io.containerd.grpc.v1.cri" .registry.mirrors. [[docker.io] ]
        エンドポイント = [ "https://bqr1dr1n.mirror.aliyuncs.com" ]
      [プラグイン。 "io.containerd.grpc.v1.cri" .registry.mirrors. [[ ... [ （
        エンドポイント = [ "https://registry.aliyuncs.com/k8sxio" ]

上記でダウンロードした containerd 圧縮パッケージには etc/systemd/system/containerd.service ファイルが含まれているため、systemd を使用して containerd をデーモン プロセスとして実行するように構成できます。これで、次のコマンドを直接実行して containerd を起動できます。

 ➜ ~ systemctlデーモンリロード
➜ ~ systemctl コンテナを有効にする--now  

起動が完了したら、containerd のローカル CLI ツール ctr や crictl などを使用してバージョンを確認できます。

 ➜ ~ ctr バージョン
クライアント：
  バージョン: v1.5.5
  リビジョン: 72cec4be58a9eb6b2910f5d10f1c01ca47d231c0
  Goバージョン: go1.16.6 
 
サーバ：
  バージョン: v1.5.5
  リビジョン: 72cec4be58a9eb6b2910f5d10f1c01ca47d231c0
  識別子: cd2894ad-fd71-4ef7-a09f-5795c7eb4c3b
 ➜ ~ crictl バージョン
バージョン: 0.1.0
ランタイム名: containerd
ランタイムバージョン: v1.5.5
ランタイム API バージョン: v1alpha2

ロードバランサー

従来の haproxy+keepalived や nginx プロキシの使用など、apiserver にロード バランサを提供する方法は多数あります。ここでは比較的新しいツール kube-vip を使用します。

kube-vip (https://kube-vip.io/) は、コントロール プレーン ノード上で Kubernetes ネイティブの HA ロード バランシングを提供できます。クラスターの高可用性を実現するために、HAProxy と Keepalived を外部で設定する必要がなくなりました。

従来、プライベート環境で Kubernetes クラスターを作成する場合、マルチコントロールプレーン クラスターを作成するためにハードウェア/ソフトウェア ロードバランサーを準備する必要がありました。ほとんどの場合、この機能を実現するために HAProxy + Keepalived を使用することを選択します。通常は、2 つのロード バランサ仮想マシンを作成し、VIP を割り当て、VIP を使用してロード バランサにサービスを提供して、VIP を介してバックエンドの Kubernetes コントローラ プレーン ノードにトラフィックをリダイレクトします。

haproxy+キープアライブ

kube-vip を使用するとどうなるでしょうか?

kube-vip

kube-vip は、静的ポッドを介してコントロール プレーン ノード上で実行できます。これらのポッドは、ARP セッションを通じて各ノード上の他のホストを識別します。 Metal LB と同様に、ロード バランサーを設定するには BGP または ARP を選択できます。 ARP モードでは、リーダーが選出され、このノードは仮想 IP を継承してクラスター内の負荷分散のリーダーになりますが、BGP モードでは、すべてのノードが VIP アドレスを通知します。

クラスターのリーダーは VIP を割り当て、構成で宣言された選択されたインターフェースにバインドします。リーダーが変更されると、まず VIP が取り消されます。または、失敗した場合は、次に選出されたリーダーによって VIP が直接割り当てられます。 VIP がホスト間で移動すると、その VIP を使用するホストは、ARP が期限切れになるまで (通常 30 秒)、以前の VIP <-> MAC アドレス マッピングを保持し、新しい VIP <-> MAC マッピングを取得します。このマッピングは、Gratuitous ARP ブロードキャストを使用して最適化できます。

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

kube-vip を使用してクラスターの高可用性を実現するには、まず master1 ノードで基本的な Kubernetes 静的 Pod リソース マニフェスト ファイルを生成します。

 ➜ ~ mkdir -p /etc/kubernetes/manifests/
 #VIPアドレスを設定する
➜ ~ エクスポート VIP=192.168.31.10
 # ネットワークカード名を設定する
➜ ~ エクスポート INTERFACE=ens33
 ➜ ~ ctr イメージをプル docker.io/plndr/kube-vip:v0.3.8
 # 静的なPodリソースリストを出力するには、次のコンテナを使用します
➜ ~ ctr 実行--rm --net-host docker.io/plndr/kube-vip:v0.3.8 vip \  
 /kube-vip マニフェストポッド \
 --インターフェース $INTERFACE \  
 --vip $VIP \  
 --コントロールプレーン \  
 --サービス\  
 --arp \  
 --リーダー選挙 | /etc/kubernetes/manifests/kube-vip.yaml を編集します。  
 APIバージョン: v1
種類: ポッド
メタデータ:
  作成タイムスタンプ: null  
名前: kube-vip
  名前空間: kube-system
仕様:
  コンテナ:
 -引数:
    - マネージャー
    環境:
    -名前: vip_arp
      値: "true"  
    -名前: vip_interface
      値: ens33
    -名前: ポート
      値: "6443"  
    -名前: vip_cidr
      値: "32"  
    -名前: cp_enable
      値: "true"  
    -名前: cp_namespace
      値: kube-system
    -名前: vip_ddns
      値: "false"  
    -名前: svc_enable
      値: "true"  
    -名前: vip_leaderelection
      値: "true"  
    -名前: vip_leaseduration
      値: "5"  
    -名前: vip_renewdeadline
      値: "3"  
    -名前: vip_retryperiod
      値: "1"  
    -名前: vip_address
      値: 192.168.31.10
    イメージ: ghcr.io/kube-vip/kube-vip:v0.3.8
    imagePullPolicy: 常に
名前: kube-vip
    リソース： {}
    セキュリティコンテキスト:
      機能:
追加：
        -NET_ADMIN
        -NET_RAW
        -SYS_TIME
    ボリュームマウント:
    - マウントパス: /etc/kubernetes/admin.conf
名前: kubeconfig
  ホストネットワーク: true  
  ボリューム:
 - ホストパス:
      パス: /etc/kubernetes/admin.conf
名前: kubeconfig
状態： {}

ここでは、vip を 192.168.31.10 に設定します。まず、master1 ノードがリーダーとして選出されます。次に、この VIP を使用してコントローラー プラットフォームを初期化します。

コントロールプレーンを初期化する

上記の関連環境設定も完了です。これで Kubeadm をインストールできます。 yum ソースを指定してインストールします。

 ➜ ~ cat <<EOF > /etc/yum.repos.d/kubernetes.repo
 [Kubernetes]
名前= Kubernetes
ベース URL = https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
有効=1
 gpgcheck=1
リポジトリ_gpgcheck=1
 gpgkey=https : //packages.cloud.google.com/yum/doc/yum-key.gpg
        https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
終了

もちろん、上記の yum ソースには科学的なインターネット アクセスが必要です。科学的にインターネットにアクセスできない場合は、インストールに Alibaba Cloud ソースを使用できます。

 ➜ ~ cat <<EOF > /etc/yum.repos.d/kubernetes.repo
 [Kubernetes]
名前= Kubernetes
ベースURL=http://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64
有効=1
 gpgcheck=0
リポジトリ_gpgcheck=0
 gpgkey =http : //mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg
        http://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg
終了

次に、kubeadm、kubelet、kubectl をインストールします。

 # --disableexcludes kubernetes以外のすべてのリポジトリを無効にします 
 ➜ ~ yum makecache 高速
➜ ~ yum インストール -y kubelet-1.22.1 kubeadm-1.22.1 kubectl-1.22.1 --disableexcludes=kubernetes  
 ➜ ~ kubeadm バージョン
kubeadm バージョン: &version.Info{メジャー: "1" 、マイナー: "22" 、GitVersion: "v1.22.1" 、GitCommit: "632ed300f2c34f6d6d15ca4cef3d3c7073412212" 、GitTreeState: "clean" 、BuildDate: "2021-08-19T15:44:22Z" 、GoVersion: "go1.16.7" 、コンパイラ: "gc" 、プラットフォーム: "linux/amd64" }

ここではバージョン v1.22.1 がインストールされており、起動時にマスター ノードの kubelet が起動するように設定されていることがわかります。

 ➜ ~ systemctl enable --now kubelet  

上記のすべての操作は、すべてのノードで構成する必要があります。

kubelet --help コマンドを実行すると、ほとんどのコマンドライン パラメータが非推奨であることがわかります。これは、公式の推奨事項では、--config を使用して構成ファイルを指定し、構成ファイルでこれらのパラメータの構成を指定するためです。詳細については、公式ドキュメント「設定ファイルを使用して Kubelet パラメータを設定する」を参照してください。このようにして、Kubernetes は動的な Kubelet 構成 (Dynamic Kubelet Configuration) をサポートできます。「ライブ クラスターでノードの Kubelet を再構成する」を参照してください。

次に、次のコマンドを使用して、master1 ノードでのクラスター初期化に使用されるデフォルト構成を出力できます。

 ➜ ~ kubeadm config print init-defaults --component-configs KubeletConfiguration > kubeadm.yaml  

次に、クラスターの初期化時に Kubernetes が必要とするイメージのアドレスを指定するように imageRepository を変更し、kube-proxy のモードを ipvs にするなど、独自のニーズに応じて構成を変更します。さらに、ここでは flannel ネットワーク プラグインをインストールするので、networking.podSubnet を 10.244.0.0/16 に設定する必要があることに注意してください。

 # kubeadm.yaml
 APIバージョン: kubeadm.k8s.io/v1beta3
ブートストラップトークン:
 - グループ:
  - システム:ブートストラップ:kubeadm:デフォルト-node-token
  トークン: abcdef.0123456789abcdef
  終了時刻: 24h0m0s
  使用法:
  - 署名
  - 認証
種類: InitConfiguration
ローカルAPIエンドポイント:
  AdvertiseAddress: 192.168.31.31 #現在のノードのイントラネットIPを指定します
  バインドポート: 6443
ノード登録:
  criSocket: /run/containerd/containerd.sock # containerd の Unix ソケット アドレスを使用する
  イメージプルポリシー: IfNotPresent
名前: マスター1
  taints: #マスターノードにtaintsを追加して、マスターノードがアプリケーションをスケジュールできないようにします
  - 効果: "NoSchedule"  
キー: "node-role.kubernetes.io/master"  
 ---  
 APIバージョン: kubeproxy.config.k8s.io/v1alpha1
種類: KubeProxyConfiguration
モード: ipvs # kube-proxy モード
---  
 APIバージョン: kubeadm.k8s.io/v1beta3
証明書ディレクトリ: /etc/kubernetes/pki
クラスター名: kubernetes
コントローラーマネージャー: {}
ドメイン名: {}
など:
地元：
    データディレクトリ: /var/lib/etcd
イメージリポジトリ: registry.aliyuncs.com/k8sxio
種類: ClusterConfiguration
 kubernetesバージョン: 1.22.1
コントロールプレーンエンドポイント: api.k8s。 local :6443 # コントロールプレーンのエンドポイントアドレスを設定する
apiサーバー:
  追加引数:
認証モード: ノード、RBAC
  コントロールプレーンのタイムアウト: 4分0秒
  certSANs: # 他のマスターノードの関連情報を追加します
  - api.k8s.local  
  -マスター1
  -マスター2
  -マスター3
  - 192.168.31.30
  - 192.168.31.31
  - 192.168.31.32
ネットワーキング：
  dnsドメイン: cluster.local  
  サービスサブネット: 10.96.0.0/12
  podSubnet: 10.244.0.0/16 # ポッドサブネットを指定します
スケジューラ: {}
 ---  
 APIバージョン: kubelet.config.k8s.io/v1beta1
認証:
  匿名：
    有効: false  
  ウェブフック:
    キャッシュTTL: 0秒
    有効: true  
  x509:
    クライアントCAファイル: /etc/kubernetes/pki/ca.crt
承認:
  モード: Webhook
  ウェブフック:
    キャッシュ承認TTL: 0秒
    キャッシュ未承認TTL: 0秒
クラスターDNS:
 - 10.96.0.10
クラスタードメイン: cluster.local  
 cpuManagerReconcilePeriod: 0秒
立ち退き圧力遷移期間: 0 秒
ファイルチェック頻度: 0 秒
healthzBindアドレス: 127.0.0.1
ヘルスポート: 10248
 httpチェック頻度: 0秒
画像の最小GC年齢: 0秒
種類: KubeletConfiguration
 cgroupDriver: systemd # cgroup ドライバーを設定する
ログ: {}
メモリスワップ: {}
ノードステータスレポート頻度: 0 秒
ノードステータス更新頻度: 0 秒
証明書を回転: true  
ランタイムリクエストタイムアウト: 0 秒
シャットダウン猶予期間: 0 秒
シャットダウン猶予期間クリティカルポッド: 0 秒
静的ポッドパス: /etc/kubernetes/manifests
ストリーミング接続アイドルタイムアウト: 0 秒
同期周波数: 0秒
ボリューム統計アグ期間: 0 秒

• 上記のリソース リストのドキュメントは非常に複雑です。上記のリソース オブジェクトに対応するプロパティを完全に理解するには、対応する godoc ドキュメント (https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3) を参照してください。

ここで注目すべきは、ClusterConfiguration ブロックの構成にコントロール プレーン アドレスを追加し、証明書の署名にドメイン名 api.k8s.local を追加して、vip にマッピングしたことです。

コントロールプレーンエンドポイント: api.k8s。 local :6443 # コントロールプレーンのエンドポイントアドレスを設定する
apiサーバー:
  追加引数:
認証モード: ノード、RBAC
  コントロールプレーンのタイムアウト: 4分0秒
  certSANs: # 他のマスターノードの関連情報を追加します
  - api.k8s.local  
  -マスター1
  -マスター2
  -マスター3
  - 192.168.31.30
  - 192.168.31.31
  - 192.168.31.32

クラスターの初期化を開始する前に、kubeadm config images pull --config kubeadm.yaml を使用して、各サーバーノード上の k8s に必要なコンテナイメージを事前にプルすることができます。

設定ファイルが準備できたら、次のコマンドを使用してまず関連するイメージをプルできます。

 ➜ ~ kubeadm config イメージ pull --config kubeadm.yaml  
 [config/images] registry.aliyuncs.com/k8sxio/kube-apiserver:v1.22.1 をプルしました
[config/images] registry.aliyuncs.com/k8sxio/kube-controller-manager:v1.22.1 をプルしました
[config/images] registry.aliyuncs.com/k8sxio/kube-scheduler:v1.22.1 をプルしました
[config/images] registry.aliyuncs.com/k8sxio/kube-proxy:v1.22.1 をプルしました
[config/images] registry.aliyuncs.com/k8sxio/pause:3.5 をプルしました
[config/images] registry.aliyuncs.com/k8sxio/etcd:3.5.0-0 をプルしました
イメージ「registry.aliyuncs.com/k8sxio/coredns:v1.8.4」のプルに失敗しました:出力:時刻= 「2021-08-31T15:09:13+08:00」  レベル= 致命的 メッセージ = "イメージをプルしています: RPC エラー: コード = NotFound 説明 = イメージ \"registry.aliyuncs.com/k8sxio/coredns:v1.8.4\" をプルして解凍できませんでした: 参照 \"registry.aliyuncs.com/k8sxio/coredns:v1.8.4\" を解決できませんでした: registry.aliyuncs.com/k8sxio/coredns:v1.8.4: 見つかりません"  
エラー: 終了ステータス 1
このエラーのスタックトレースを表示するには、以下を実行します。  と  --v=5以上 

上記の coredns イメージをプルするときにエラーが発生しました。画像が見つかりませんでした。手動でイメージを取得し、イメージ アドレスに再度タグを付けることができます。

 ➜ ~ ctr -n k8s.io i をプルします docker.io/coredns/coredns:1.8.4
 ➜ ~ ctr -n k8s.io i タグ docker.io/coredns/coredns:1.8.4 registry.aliyuncs.com/k8sxio/coredns:v1.8.4

次に、上記の構成ファイルを使用して、master1 ノードを初期化できます。

 ➜ ~ kubeadm init --upload-certs --config kubeadm.yaml  
 [init] Kubernetesバージョンの使用: v1.22.1
 [プリフライト] プリフライトチェックの実行
[事前準備] Kubernetes クラスターの設定に必要なイメージを取得する
...... 
 
 Kubernetes コントロールプレーンが正常に初期化されました。 
 
クラスターの使用を開始するには、通常のユーザーとして以下を実行する必要があります。 
 
  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config 
 
あるいは、rootユーザーの場合は、次のコマンドを実行できます。 
 
  KUBECONFIG=/etc/kubernetes/admin.conf をエクスポートします。 
 
ここで、クラスターにポッド ネットワークをデプロイする必要があります。
 「kubectl apply -f [podnetwork].yaml」を実行します。  以下にリストされているオプションのいずれかを使用します。
  https://kubernetes.io/docs/concepts/cluster-administration/addons/ 
 
今すぐ参加できます 任意の数のコントロール プレーン ノードで、それぞれに対して次のコマンドを rootとして実行します。 
 
  kubeadm は api.k8sに参加します。ローカル:6443 --token abcdef.0123456789abcdef \  
 --discovery-token-ca-cert-hash sha256:435fbc28490d1f897337923c19ec27bcf3639e9fe84e8448177777d23cae4176 \  
 --コントロールプレーン --証明書キー 7892cd62c5ab60b28b462af32c7e49aa73d5fd4f723352f3af6546a74e465abc   
 
証明書キーによりクラスターの機密データにアクセスできるようになるため、秘密にしておいてください。
安全対策として、アップロードされた証明書は2 時間以内に削除されます。必要に応じて、
 「kubeadm init フェーズ upload-certs --upload-certs」  後で証明書を再読み込みします。 
 
参加するには 任意の数のワーカーノードで、各ワーカーノードで次のコマンドをrootとして実行します。 
 
 kubeadm は api.k8sに参加します。ローカル:6443 --token abcdef.0123456789abcdef \  
 --ディスカバリートークンCA証明書ハッシュsha256:435fbc28490d1f897337923c19ec27bcf3639e9fe84e8448177777d23cae4176  

ここで初期化される --upload-certs フラグは、すべてのコントロール プレーン インスタンス間の共有証明書をクラスターにアップロードするために使用されます。次に、インストールプロンプトに従って kubeconfig ファイルをコピーします。

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

その後、上記のプロンプトに従って他のコントロール プレーン ノードを追加できます。

コントロールプレーンの追加

他の各コントロール プレーン ノードに対して、最初のノード master1 で以前に kubeadm init 出力によって提供された join コマンドを実行して、コントロール プレーン ノードを追加します。

 ➜ ~ kubeadm はapi.k8s に参加します。ローカル:6443 --トークン abcdef.0123456789abcdef --ディスカバリトークンca証明書ハッシュ sha256:435fbc28490d1f897337923c19ec27bcf3639e9fe84e8448177777d23cae4176 --コントロールプレーン --証明書キー 7892cd62c5ab60b28b462af32c7e49aa73d5fd4f723352f3af6546a74e465abc  
 [プリフライト] プリフライトチェックの実行
[プリフライト]クラスターから構成を読み取っています...
 [プリフライト] 参考までに:この設定ファイルは  'kubectl -n kube-system get cm kubeadm-config -o yaml'  
 [preflight] 新しいコントロールプレーンインスタンスを初期化する前に事前チェックを実行する
......
このノードはクラスターに参加し、新しいコントロール プレーン インスタンスが作成されました。 
 
 * 証明書署名要求がapiserverに送信され、承認が受信されました。
 * Kubelet に新しい安全な接続の詳細が通知されました。
 * コントロール プレーン (マスター) ラベルとテイントが新しいノードに適用されました。
 * Kubernetes コントロール プレーン インスタンスがスケールアップされました。
 *ローカルの/stacked etcd クラスターに新しい etcd メンバーが追加されました。 
 
このノードからクラスターの管理を開始するには、通常のユーザーとして以下を実行する必要があります。 
 
 mkdir -p $HOME/.kube
 sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
 sudo chown $(id -u):$(id -g) $HOME/.kube/config 
 
 「kubectl get nodes」を実行します このノードがクラスターに参加することを確認します。

上記の join コマンドは、他の 2 つのノード (master2 と master3) でも実行する必要があることに注意してください。上記のコマンドの --control-plane は、kubeadm join に新しいコントロール プレーンを作成するように通知し、--certificate-key はクラスター内の kubeadm-certs Secret からコントロール プレーン証明書をダウンロードし、指定されたキーを使用して復号化します。

2 つのノードがクラスターに追加された後、ノード上で kube-vip を実行し、現在のノードを kube-vip のメンバーにする必要もあります。同様に、次のコマンドを実行します。

 #VIPアドレスを設定する
➜ ~ エクスポート VIP=192.168.31.10
 # ネットワークカード名を設定する
➜ ~ エクスポート INTERFACE=ens33
 ➜ ~ ctr イメージをプル docker.io/plndr/kube-vip:v0.3.8
 # 静的なPodリソースリストを出力するには、次のコンテナを使用します
➜ ~ ctr 実行--rm --net-host docker.io/plndr/kube-vip:v0.3.8 vip \  
 /kube-vip マニフェストポッド \
 --インターフェース $INTERFACE \  
 --vip $VIP \  
 --コントロールプレーン \  
 --サービス\  
 --arp \  
 --リーダー選挙 | /etc/kubernetes/manifests/kube-vip.yaml を編集します。  

kube-vip の静的 Pod マニフェストが作成されると、kube-vip の Pod が起動され、期待どおりに実行されていることを確認できます。

 ➜ ~ kubectl get pods -A | grep vip
 kube-system kube-vip-master1 1/1 実行中 1 7分42秒
kube-system kube-vip-master2 1/1 実行中 0 4分24秒
kube-system kube-vip-master3 1/1 実行中 0 14秒

この時点でコントロール プレーン ノードは準備完了です。

 ➜ ~ kubectl ノードを取得する
名前ステータス 役割 年齢 バージョン
master1 コントロールプレーン準備完了、マスター 9 分 18 秒 v1.22.1
 master2 コントロールプレーン準備完了、マスター 7m11s v1.22.1
 master3 コントロールプレーン準備完了、マスター 5m9s v1.22.1

ワーカーノードの追加

次に、master1 の初期化後にプロンプ​​ト表示される join コマンドを使用して、node1 作業ノードをクラスターに追加できます。マスター 1 ノードの $HOME/.kube/config ファイルをノード 1 の対応するファイルにコピーし、kubeadm、kubelet、および kubectl (オプション) をインストールして、上記の初期化が完了した後に表示される join コマンドを実行することを忘れないでください。

 ➜ ~ kubeadm はapi.k8s に参加します。ローカル:6443 --token abcdef.0123456789abcdef \  
 > --discovery-token-ca-cert-hash sha256:435fbc28490d1f897337923c19ec27bcf3639e9fe84e8448177777d23cae4176  
 [プリフライト] プリフライトチェックの実行
[プリフライト]クラスターから構成を読み取っています...
 [プリフライト] 参考までに:この設定ファイルは  'kubectl -n kube-system get cm kubeadm-config -o yaml'  
 [kubelet-start] kubelet 設定をファイル"/var/lib/kubelet/config.yaml"に書き込みます 
 [kubelet-start]フラグ付きのkubelet 環境ファイルをファイル"/var/lib/kubelet/kubeadm-flags.env"に書き込みます 
 [kubelet-start] kubeletの起動
[kubelet-start] kubeletがTLS ブートストラップを実行するのを待機しています... 
 
このノードはクラスターに参加しました:
 * 証明書署名要求がapiserverに送信され、応答が受信されました。
 * Kubelet に新しい安全な接続の詳細が通知されました。 
 
 「kubectl get nodes」を実行します コントロールプレーンでこのノードがクラスターに参加することを確認します。

• 上記の join コマンドを忘れた場合は、kubeadm token create --print-join-command コマンドを使用して再度取得できます。

実行が成功したら、get nodes コマンドを実行します。

 ➜ ~ kubectl ノードを取得する
名前ステータス 役割 年齢 バージョン
master1 コントロールプレーン準備完了、マスター 9 分 18 秒 v1.22.1
 master2 コントロールプレーン準備完了、マスター 7m11s v1.22.1
 master3 コントロールプレーン準備完了、マスター 5m9s v1.22.1
 node1 NotReady <なし> 24s v1.22.1

NotReady 状態であることがわかります。これは、ネットワーク プラグインがインストールされていないためです。次に、ネットワーク プラグインをインストールします。ドキュメント https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/ で独自のネットワーク プラグインを選択できます。ここでフランネルをインストールします:

 ➜ ~ wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
 # ノードに複数のネットワークカードがある場合は、リソースリストファイルで内部ネットワークカードを指定する必要があります。
 # kube-flannelコンテナの下にあるkube-flannel-dsという名前のDaemonSetを検索します
➜ ~ vi kube-flannel.yml
 ......
コンテナ:
 -名前: kube-flannel
  イメージ: quay.io/coreos/flannel:v0.14.0
  指示：
  - /opt/bin/flanneld
  引数:
  - --ip-masq  
  - --kube-サブネットマネージャー 
  - --iface=eth0 # 複数のネットワークカードがある場合は、内部ネットワークカードの名前を指定します 
 ......
 ➜ ~ kubectl apply -f kube-flannel.yml # flannelネットワークプラグインをインストールします

しばらくしてから Pod の実行ステータスを確認します。

 ➜ ~ kubectl get ポッド -n kube-system
名前準備完了 ステータス 再起動 年齢
coredns-7568f67dbd-lvcd5 1/1 実行中 0 30m
 coredns-7568f67dbd-shfrk 1/1 実行中 0 30m
 etcd-master1 1/1 実行中 0 45分
etcd-master2 1/1 実行中 0 45分
etcd-master3 1/1 実行中 1 (46 分前) 54 分
kube-apiserver-master1 1/1 実行中 4 (45 分前) 58 分
kube-apiserver-master2 1/1 実行中 2 (45 分前) 56 分
kube-apiserver-master3 1/1 実行中 1 (46 分前) 54 分
kube-controller-manager-master1 1/1 実行中 15 (48 分前) 58 分
kube-controller-manager-master2 1/1 実行中 1 (47 分前) 56 分
kube-controller-manager-master3 1/1 実行中 0 54分
kube-flannel-ds-4js7f 1/1 実行中 0 38分
kube-flannel-ds-hch26 1/1 ランニング 0 38m
 kube-flannel-ds-l6xzv 1/1 ランニング 0 38m
 kube-flannel-ds-qpzqq 1/1 ランニング 0 38m
 kube-proxy-fpxp8 1/1 実行中 0 54分
kube-proxy-qdsfq 1/1 実行中 0 56分
kube-proxy-ww9b2 1/1 実行中 0 58分
kube-proxy-zcw98 1/1 実行中 0 50m
 kube-scheduler-master1 1/1 実行中 15 (48 分前) 58 分
kube-scheduler-master2 1/1 実行中 0 56分
kube-scheduler-master3 1/1 実行中 1 (47 分前) 54 分
kube-vip-master1 1/1 実行中 2 (48 分前) 58 分
kube-vip-master2 1/1 実行中 1 (47分前) 55分
kube-vip-master3 1/1 実行中 0 51分

• ネットワーク プラグインを展開し、ifconfig コマンドを実行すると、通常、新しく追加された 2 つの仮想デバイス cni0 と flannel1 が表示されます。ただし、cni0 デバイスが表示されなくても、あまり心配する必要はありません。 /var/lib/cni ディレクトリが存在するかどうかを確認できます。存在しない場合は、デプロイメントに問題があるのではなく、ノード上でまだアプリケーションが実行されていないことを意味します。ディレクトリが作成され、cni0 デバイスも作成されることを確認するには、ノード上で Pod を実行するだけです。

ネットワーク プラグインは正常に実行され、ノードのステータスは正常です。

 ➜ ~ kubectl ノードを取得する
名前ステータス 役割 年齢 バージョン
master1 コントロールプレーン準備完了、マスター 9 分 18 秒 v1.22.1
 master2 コントロールプレーン準備完了、マスター 7m11s v1.22.1
 master3 コントロールプレーン準備完了、マスター 5m9s v1.22.1
 node1 準備完了 <なし> 24s v1.22.1

高可用性のテスト

上記では、3 つのマスター ノードを持つ高可用性 Kubernetes クラスターを構築しました。次に、高可用性が有効かどうかをテストしてみましょう。

まず、kube-vip の Pod ログを確認します。

 ➜ ~ kubectl ログ -f kube-vip-master1 -n kube-system
時刻= "2021-09-07T08:53:24Z"  レベル=info msg= "サーバーが起動しました"  
時刻= "2021-09-07T08:53:24Z"  レベル=info msg= "ARP エンジンを使用して Kube-vip マネージャーを起動しています"  
時刻= "2021-09-07T08:53:24Z"  レベル=info msg= "名前空間 [kube-system]、ハイブリッド モード [true]"  
時刻= "2021-09-07T08:53:24Z"  レベル=info msg= "クラスター メンバーシップの開始、名前空間 [kube-system]、ロック名 [plndr-svcs-lock]、ID [master1]"  
 I0907 08:53:24.205669 1 leaderselection.go:243]リーダー リース kube-system/plndr-svcs-lock を取得しようとしています...
時刻= "2021-09-07T08:53:24Z"  レベル=info msg= "クラスターメンバーシップの開始、名前空間 [kube-system]、ロック名 [plndr-cp-lock]、ID [master1]"  
 I0907 08:53:24.206162 1 leaderselection.go:243]リーダー リース kube-system/plndr-cp-lock を取得しようとしています...
 ......
時刻= "2021-09-07T08:55:55Z"  レベル=info msg= "ノード [master3] がクラスターのリーダーシップを引き継いでいます"  
時刻= "2021-09-07T08:55:55Z"  レベル=info msg= "新しいリーダーが選出されました: master3"  

master3 がリーダーになったことがわかります。次に、master3 ノードをシャットダウンし、他の kube-vip のログの変更を確認します。

 ➜ ~ kubectl ログ -f kube-vip-master2 -n kube-system
 ......
時刻= "2021-09-07T08:55:55Z"  レベル=info msg= "ノード [master3] がクラスターのリーダーシップを引き継いでいます"  
時刻= "2021-09-07T08:55:55Z"  レベル=info msg= "新しいリーダーが選出されました: master3"  
時刻= "2021-09-07T10:28:58Z"  レベル=info msg= "ノード [master1] がクラスターのリーダーシップを引き受けます"  
 ......

master1 ノードが kube-vip のリーダーを取得したことがわかります。これは、この時点で vip が master1 ノードにバインドされており、クラスターに引き続き正常にアクセスできることを意味します。

ダッシュボード

v1.22.1 クラスターには、ダッシュボードの最新バージョン 2.0+ をインストールする必要があります。

 # 以下の方法を使用することをお勧めします
➜ ~ wget https://raw.githubusercontent.com/kubernetes/dashboard/v2.3.1/aio/deploy/recommended.yaml
 ➜ ~ vi 推奨.yaml
 # サービスタイプをNodePortに変更する
......
種類: サービス
APIバージョン: v1
メタデータ:
  ラベル:
    k8s-app: kubernetes-ダッシュボード
名前: kubernetes-dashboard
  名前空間: kubernetes-dashboard
仕様:
  ポート:
    - ポート: 443
      ターゲットポート: 8443
  セレクタ：
    k8s-app: kubernetes-ダッシュボード
  type: NodePort # type=NodePort を追加して NodePort タイプのサービスにします
......

直接作成:

 ➜ ~ kubectl apply -f 推奨.yaml

新しいバージョンのダッシュボードは、デフォルトで kubernetes-dashboard 名前空間にインストールされます。

 ➜ ~ kubectl get pods -n kubernetes-dashboard -o wide
名前準備完了 ステータス 再起動 年齢 IP ノード 指名ノード 準備完了 ゲート
dashboard-metrics-scraper-856586f554-pllvt 1/1 実行中 0 24分 10.88.0.7 マスター <なし> <なし>
 kubernetes-dashboard-76597d7df5-82998 1/1 実行中 0 21m 10.88.0.2 node2 <なし> <なし>

よく見ると、上記の Pod に割り当てられた IP セグメントは、上記で自動的にインストールされた CoreDNS を含めて 10.88.xx.xx であることがわかります。 podSubnet を 10.244.0.0/16 に設定しませんでしたか?まずCNI構成ファイルを確認しましょう。

 ➜ ~ ls -la /etc/cni/net.d/
合計 8
 drwxr-xr-x 2 1001 docker 67 8月31日 16:45 .
 drwxr-xr-x。 3 1001 docker 19 7月 30 01:13 ..
 -rw-r --r-- 1 1001 docker 604 7月30日 01:13 10-containerd-net.conflist  
 -rw-r --r-- 1 ルート ルート 292 8月 31 16:45 10-flannel.conflist  

2 つの構成が含まれていることがわかります。1 つは 10-containerd-net.conflist で、もう 1 つは上記で作成した Flannel ネットワーク プラグインによって生成された構成です。ぜひこの構成のフランネルを使いたいですね。 containerd に付属する cni プラグインの設定を確認できます。

 ➜ ~ cat /etc/cni/net.d/10-containerd-net.conflist
 {
 "cniバージョン" : "0.4.0" 、
 「名前」 : 「containerd-net」 、
 「プラグイン」 : [
    {
 「タイプ」 : 「ブリッジ」 、
 「ブリッジ」 : 「cni0」 、
 "isGateway" : true 、
 "ipMasq" : true 、
 "promiscMode" : true 、
 「ipam」 :{
 「タイプ」 : 「ホストローカル」 、
 「範囲」 : [
          [{
 「サブネット」 : 「10.88.0.0/16」  
          }],
          [{
 「サブネット」 : 「2001:4860:4860::/64」  
          }]
        ]、
 「ルート」 : [
          { "dst" : "0.0.0.0/0" },
          { "dst" : "::/0" }
        ]
      }
    },
    {
 「タイプ」 : 「ポートマップ」 、
 「機能」 : { 「ポートマッピング」 : true }
    }
  ]
 }

上記の IP セグメントは正確に 10.88.0.0/16 ですが、cni プラグインのタイプはブリッジ ネットワークであり、ブリッジの名前は cni0 であることがわかります。

 ➜ ~ ip a
 ...
 6: cni0: <BROADCAST、MULTICAST、PROMISC、UP、LOWER_UP> mtu 1500 qdisc noqueue 状態 UPグループ デフォルトのqlen 1000
    リンク/イーサ 9a:e7:eb:40:e8:66 brd ff:ff:ff:ff:ff:ff
    inet 10.88.0.1/16 brd 10.88.255.255 スコープグローバルcni0
       valid_lft 永久に preferred_lft 永久に
    inet6 2001:4860:4860::1/64 スコープグローバル 
       valid_lft 永久に preferred_lft 永久に
    inet6 fe80::98e7:ebff:fe40:e866/64 スコープ リンク
       valid_lft 永久に preferred_lft 永久に
...

ただし、ブリッジ ネットワークを使用するコンテナーは複数のホスト間で通信できません。クロスホスト通信には、フランネルやCalicoなどの他のCNIプラグインが必要です。上記でインストールしました。ここには2つのCNI構成があるため、10-Containerd-net.Conflist構成を削除する必要があります。

 ➜〜mv/etc/cni/net.d/10-containerd-net.conflist /etc/cni/net.d/10-containerd-net.conflist.bak
 ifconfig cni0 down && ip link delete cni0
 ➜〜SystemCtl Daemon-Reload
 ➜〜systemctl restart containerd kubelet

次に、CorednsとDashboard Podsを再構築することを忘れないでください。PODのIPアドレスは再構成後に正常になります。

 ➜〜kubectl get pods -n kubernetes -dashboard -o幅
名前準備完了 ステータス 再起動 年齢 IP ノード 指名ノード 準備完了 ゲート
DashBoard-Metrics-Scraper-856586F554-TP8M5 1/1 RUNNIS 0 42S 10.244.1.6 node2 <NODE <NOE> <NOGNE>
 kubernetes-dashboard-76597d7d7df5-9rmbx 1/1 running 0 66S 10.244.1.5 node2 <newne> <negn <なし>
 ➜〜kubectl get pods -n kube -system -o wide -l k8s -app = kube -dns
名前準備完了 ステータス 再起動 年齢 IP ノード 指名ノード 準備完了 ゲート
coredns-7568f67dbd-n7bfx 1/1 running 0 5m40s 10.244.1.2 node2 <newne> <なし>
 coredns-7568f67dbd-plrv8 1/1 running 0 3m47s 10.244.1.4 node2 <nea> <なし> 

ダッシュボードのnodeportポートをご覧ください。

 ➜〜kubectl get svc -n kubernetes -dashboard
名前タイプ クラスター IP 外部 IP ポート 年齢
DashBoard-Metrics-ScraperClusterip 10.99.37.172 <なし> 8000/TCP 25M
 Kubernetes-Dashboard nodePort 10.103.102.27 <None> 443：31050/TCP 25M

次に、上記のポート31050からダッシュボードにアクセスできます。HTTPSを使用することを忘れないでください。 Chromeが有効になっていない場合は、Firefoxを使用してテストできます。 Firefoxなしでページを以下に開くことができない場合は、次のページの信頼証明書をクリックできます。

信託証明書

信頼後、ダッシュボードのログインページにアクセスできます。

ダッシュボードログインページ

次に、グローバルなすべてのアクセス許可を持つユーザーを作成して、ダッシュボードにログインします。

 ＃admin.yaml
種類: ClusterRoleBinding
 apiバージョン: rbac。認証.k8s.io/v1
メタデータ:
名前：管理者
ロールリファレンス:
  種類: ClusterRole
名前: クラスター管理者
  apiGroup : rbac.authorization.k8s.io
科目:
 - 種類: サービスアカウント
名前：管理者
  名前空間: kubernetes-dashboard
 ---  
 APIバージョン: v1
種類: サービスアカウント
メタデータ:
名前：管理者
  名前空間: kubernetes-dashboard

直接作成：

 ➜〜kubectl apply -f admin.yaml
 ➜〜kubectl get secret -n kubernetes-dashboard | grep admin-token
 admin-token-lwmmx kubernetes.io/service-account-token 3 1d
 ➜〜kubectl Get Secret Admin -Token -Lwmmx -o Jsonpath = {。データ。Token} -n Kubernetes -Dashboard | base64 -d
 ＃base64の後に長い文字列が生成されます

次に、上記のbase64のデコードされた文字列をトークンとして使用して、ダッシュボードにログインします。新しいバージョンもダークモードを追加します：

K8Sダッシュボード

最後に、KubeAdMを使用して、Coredns、IPV、Flannel、Containd、およびKube-VIPコンポーネントを使用して、V1.22.1の非常に利用可能なKubernetesクラスターを構築しました。

クリーニング

クラスターのインストール中に他の問題に遭遇した場合、次のコマンドを使用してリセットできます。

 ➜〜kubeadmリセット
ifconfig cni0 down && ip link delete cni0
 ifconfig flannel.1 down && ip link delete flannel.1
 ➜〜rm -rf/var/lib/cni/