Containerd コンテナ ランタイムを使用して Kubernetes クラスターをデプロイする

[[421025]]

前回は、containerd の基本的な使い方を紹介し、Docker コンテナ ランタイムの既存の Kubernetes クラスターを containerd に切り替える方法を学びました。次に、kubeadm を使用して、containerd をコンテナ ランタイムとして使用し、Kubernetes クラスターをゼロから構築します。ここでは最新バージョン v1.22.1 をインストールします。

環境の準備

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

 ➜ ~ cat /etc/hosts
 192.168.31.30 マスター
192.168.31.95 ノード1
 192.168.31.215 ノード2

• ノードのホスト名には標準の 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

bridge-nf は、netfilter が Linux ブリッジ上の IPv4/ARP/IPv6 パケットをフィルタリングできるようにします。たとえば、net.bridge.bridge-nf-call-iptables=1 を設定すると、パケットを転送するときにレイヤー 2 ブリッジも iptables FORWARD ルールによってフィルタリングされます。一般的なオプションは次のとおりです。

• net.bridge.bridge-nf-call-arptables: arptables の FORWARD でブリッジ ARP パケットをフィルタリングするかどうか
• net.bridge.bridge-nf-call-ip6tables: ip6tables チェーンで IPv6 パケットをフィルタリングするかどうか
• net.bridge.bridge-nf-call-iptables: iptables チェーンで IPv4 パケットをフィルタリングするかどうか
• net.bridge.bridge-nf-filter-vlan-tagged: iptables/arptables で VLAN タグ付きのパケットをフィルタリングするかどうか。

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

 ➜ ~ 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

kubeadm を使用して Kubernetes をデプロイする

上記の関連環境設定も完了です。これで 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 を再構成する」を参照してください。

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

 ➜ ~ 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.30 #マスターノードのイントラネットIPを指定します
  バインドポート: 6443
ノード登録:
  criSocket: /run/containerd/containerd.sock # containerd の Unix ソケット アドレスを使用する
  イメージプルポリシー: IfNotPresent
名前: マスター
  taints: #マスターノードにtaintsを追加して、マスターノードがアプリケーションをスケジュールできないようにします
  - 効果: "NoSchedule"  
キー: "node-role.kubernetes.io/master"   
 
 ---  
 APIバージョン: kubeproxy.config.k8s.io/v1alpha1
種類: KubeProxyConfiguration
モード: ipvs # kube-proxy モード
 
 ---  
 apiサーバー:
  コントロールプレーンのタイムアウト: 4分0秒
APIバージョン: kubeadm.k8s.io/v1beta3
証明書ディレクトリ: /etc/kubernetes/pki
クラスター名: kubernetes
コントローラーマネージャー: {}
ドメイン名: {}
など:
地元：
    データディレクトリ: /var/lib/etcd
イメージリポジトリ: registry.aliyuncs.com/k8sxio
種類: ClusterConfiguration
 kubernetesバージョン: 1.22.1
ネットワーキング：
  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) を参照してください。

クラスターの初期化を開始する前に、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
 docker.io/coredns/coredns:1.8.4: 解決済み |++++++++++++++++++++++++++++++++++++++++++++|
インデックス-sha256:6e5a02c21641597998b4be7cb5eb1e7b02c0d8d23cce4dd09f4682d463798890: 完了 |++++++++++++++++++++++++++++++++++++++++++|
 manifest-sha256:10683d82b024a58cc248c468c2632f9d1b260500f7cd9bb8e73f751048d7d6d4: 完了 |++++++++++++++++++++++++++++++++++++++++++|
レイヤー-sha256:bc38a22c706b427217bcbd1a7ac7c8873e75efdd0e59d6b9f069b4b243db4b4b: 完了 |++++++++++++++++++++++++++++++++++++++++++|
 config-sha256:8d147537fb7d1ac8895da4d55a5e53621949981e2e6460976dae812f83d84a44: 完了 |++++++++++++++++++++++++++++++++++++++++++++|
レイヤー-sha256:c6568d217a0023041ef9f729e8836b19f863bcdb612bb3a329ebc165539f5a80: 存在します |++++++++++++++++++++++++++++++++++++++++++|
経過時間: 12.4秒 合計: 12.0 M (991.3 KiB/s)
 linux/amd64 sha256:6e5a02c21641597998b4be7cb5eb1e7b02c0d8d23cce4dd09f4682d463798890 を解凍しています...
完了: 410.185888 ミリ秒
➜ ~ ctr -n k8s.io i タグ docker.io/coredns/coredns:1.8.4 registry.aliyuncs.com/k8sxio/coredns:v1.8.4

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

 ➜ ~ kubeadm init --config kubeadm.yaml  
 [init] Kubernetesバージョンの使用: v1.22.1
 [プリフライト] プリフライトチェックの実行
[事前準備] Kubernetes クラスターの設定に必要なイメージを取得する
[プリフライト] 1分ほどかかる場合があります インターネット接続の速度に応じて、 1～ 2時間 
 [プリフライト] このアクションも実行できます 事前に「kubeadm config images pull」を使用して 
 [certs] certificateDir フォルダ"/etc/kubernetes/pki"を使用します 
 [certs] 「ca」証明書を生成し、  鍵 
 [certs] 「apiserver」証明書を生成し、  鍵 
 [certs] apiserver 提供証明書は DNS 名に対して署名されています[kubernetes kubernetes.デフォルトのKubernetes。デフォルト.svc kubernetes。デフォルトは.svc.cluster です。ローカルマスター]およびIP [10.96.0.1 192.168.31.30]
 [certs] 「apiserver-kubelet-client」証明書を生成し、  鍵 
 [certs] 「front-proxy-ca」証明書を生成し、  鍵 
 [certs] 「front-proxy-client」証明書を生成し、  鍵 
 [certs] 「etcd/ca」証明書を生成し、  鍵 
 [certs] 「etcd/server」証明書を生成し、  鍵 
 [certs] etcd/server 提供証明書はDNS 名 [localhost master]およびIP [192.168.31.30 127.0.0.1 ::1]に対して署名されています
[certs] 「etcd/peer」証明書を生成し、  鍵 
 [certs] etcd/ピアサービング証明書は、DNS名 [localhost master]およびIP [192.168.31.30 127.0.0.1 ::1]に対して署名されています
[certs] 「etcd/healthcheck-client」証明書を生成し、  鍵 
 [certs] 「apiserver-etcd-client」証明書を生成し、  鍵 
 [certs] 「sa」を生成しています 鍵 そして 公共 鍵 
 [kubeconfig] kubeconfig フォルダ「/etc/kubernetes」を使用する 
 [kubeconfig] 「admin.conf」 kubeconfigファイルの書き込み
[kubeconfig] 「kubelet.conf」 kubeconfigファイルの書き込み
[kubeconfig] 「controller-manager.conf」 kubeconfigファイルの書き込み
[kubeconfig] 「scheduler.conf」 kubeconfigファイルの書き込み
[kubelet-start]フラグ付きのkubelet 環境ファイルをファイル"/var/lib/kubelet/kubeadm-flags.env"に書き込みます 
 [kubelet-start] kubelet 設定をファイル"/var/lib/kubelet/config.yaml"に書き込みます 
 [kubelet-start] kubeletの起動
[コントロールプレーン] マニフェストフォルダ「/etc/kubernetes/manifests」を使用する 
 [コントロールプレーン]静的ポッドマニフェストを作成しています  「kube-apiserver」  
 [コントロールプレーン]静的ポッドマニフェストを作成しています  「kube-コントローラー-マネージャー」  
 [コントロールプレーン]静的ポッドマニフェストを作成しています  「kube-スケジューラ」  
 [etcd]静的ポッドマニフェストの作成 ローカルetcd​   「/etc/kubernetes/マニフェスト」  
 [wait-control-plane] kubeletがコントロールプレーンを起動するのを待っています ディレクトリ「/etc/kubernetes/manifests」からの静的ポッド。これには最大4分かかる場合があります
[apiclient] 12.501933秒後にすべてのコントロールプレーンコンポーネントが正常になりました
[upload-config] ConfigMap 「kubeadm-config」で使用される構成を保存します  「kube-system」名前空間内
[kubelet] ConfigMap 「kubelet-config-1.22」の作成 クラスター内のkubeletの設定を含む名前空間kube-system
 [upload-certs] フェーズをスキップします。 --upload-certsを参照してください 
 [mark-control-plane]ラベルを追加して、ノード マスターをコントロール プレーンとしてマークします: [node-role.kubernetes.io/master(非推奨) node-role.kubernetes.io/control-plane node.kubernetes.io/exclude- from -external- load -balancers ]
 [mark-control-plane] taint を追加してノードマスターをコントロール プレーンとしてマークします [node-role.kubernetes.io/master:NoSchedule]
 [bootstrap-token] 使用トークン: abcdef.0123456789abcdef
 [bootstrap-token] ブートストラップトークン、cluster-info ConfigMap、RBAC ロールの設定
[bootstrap-token] RBACルールを設定して、Node Bootstrapトークンがノードを取得できるようにしました。
 [bootstrap-token] RBACルールを設定して、 Node BootstrapトークンがCSRを投稿できるようにしました。  注文 ノードが長期証明書の資格情報を取得するため
[bootstrap-token] csrapprover コントローラがノード ブートストラップ トークンからのCSR を自動的に承認できるようにRBAC ルールを構成しました。
 [bootstrap-token] RBACルールを設定して証明書のローテーションを許可しました クラスター内のすべてのノードクライアント証明書
[bootstrap-token] 「kube-public」名前空間に「 cluster-info」 ConfigMapを作成する
[kubelet-finalize] 「/etc/kubernetes/kubelet.conf」を更新しています ローテーション可能なkubeletクライアント証明書を指し示し、  鍵 
 [アドオン] 必須アドオンを適用しました: CoreDNS
 [アドオン] 必須アドオンを適用しました: kube-proxy 
 
 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 join 192.168.31.30:6443 --token abcdef.0123456789abcdef \  
 --discovery-token-ca-cert-hash sha256:8c1f43da860b0e7bd9f290fe057f08cf7650b89e650ff316ce4a9cad3834475c  

インストールプロンプトに従って kubeconfig ファイルをコピーします。

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

次に、kubectl コマンドを使用して、マスター ノードが正常に初期化されたかどうかを確認できます。

 ➜ ~ kubectl ノードを取得する
名前ステータス 役割 年齢 バージョン
マスター コントロール プレーン準備完了、マスター 2m10s v1.22.1

ノードの追加

事前にクラスターの構成と操作を初期化し、マスター ノード上の $HOME/.kube/config ファイルをノードの対応するファイルにコピーし、kubeadm、kubelet、kubectl (オプション) をインストールして、初期化が完了したらプロンプトが表示される join コマンドを実行することを忘れないでください。

 ➜ ~ kubeadm join 192.168.31.30:6443 --token abcdef.0123456789abcdef \  
 > --discovery-token-ca-cert-hash sha256:8c1f43da860b0e7bd9f290fe057f08cf7650b89e650ff316ce4a9cad3834475c  
 [プリフライト] プリフライトチェックの実行
[プリフライト] 警告:コンテナ ランタイムとの通信に使用するインターフェイスを作成できませんでした:コンテナ ランタイムにはdocker が必要です: exec : "docker" : 実行可能ファイルが$PATHに見つかりません
[プリフライト]クラスターから構成を読み取っています...
 [プリフライト] 参考までに:この設定ファイルは  '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 ノードを取得する
名前ステータス 役割 年齢 バージョン
マスター 準備完了コントロールプレーン、マスター 47m v1.22.1
 node2 NotReady <なし> 46秒 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-5mg59 1/1 実行中 0 8分32秒
coredns-7568f67dbd-b685t 1/1 実行中 0 8分31秒
etcd-master 1/1 実行中 0 66分
kube-apiserver-master 1/1 実行中 0 66 分
kube-controller-manager-master 1/1 実行中 0 66分
kube-flannel-ds-dsbt6 1/1 ランニング 0 11m
 kube-flannel-ds-zwlm6 1/1 ランニング 0 11m
 kube-proxy-jq84n 1/1 実行中 0 66分
kube-proxy-x4hbv 1/1 実行中 0 19分
kube-scheduler-master 1/1 実行中 0 66 分

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

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

 ➜ ~ kubectl ノードを取得する
名前ステータス 役割 年齢 バージョン
マスター 準備完了コントロールプレーン、マスター 111m v1.22.1
 node2 準備完了 <なし> 64m v1.22.1

同じ方法を使用して別のノードを追加します。

ダッシュボード

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 永久に
...

ただし、ブリッジ ネットワークを使用するコンテナーは複数のホスト間で通信できません。ホスト間の通信には、上記でインストールされた Flannel や Calico などの他の cni プラグインを使用する必要があります。ここでは 2 つの cni 構成があるため、10-containerd-net.conflist 構成を削除する必要があります。このディレクトリに複数の cni 設定ファイルがある場合、kubelet はファイル名の辞書順で最初のファイルを設定ファイルとして使用します。したがって、containerd-net プラグインがデフォルトで選択されます。

 ➜ ~ mv /etc/cni/net.d/10-containerd-net.conflist /etc/cni/net.d/10-containerd-net.conflist.bak
 ➜ ~ ifconfig cni0 ダウン && ip リンク削除cni0
 ➜ ~ systemctlデーモンリロード
➜ ~ systemctl コンテナを再起動します。kubelet

次に、coredns と dashboard Pod を再構築することを忘れないでください。再構築後、ポッドの IP アドレスは正常になります。

 ➜ ~ kubectl get pods -n kubernetes-dashboard -o wide
名前準備完了 ステータス 再起動 年齢 IP ノード 指名ノード 準備完了 ゲート
dashboard-metrics-scraper-856586f554-tp8m5 1/1 実行中 0 42s 10.244.1.6 node2 <なし> <なし>
 kubernetes-dashboard-76597d7df5-9rmbx 1/1 実行中 0 66s 10.244.1.5 node2 <なし> <なし>
 ➜ ~ kubectl get pods -n kube-system -o Wide -l k8s-app=kube-dns
名前準備完了 ステータス 再起動 年齢 IP ノード 指名ノード 準備完了 ゲート
coredns-7568f67dbd-n7bfx 1/1 実行中 0 5分40秒 10.244.1.2 node2 <なし> <なし>
 coredns-7568f67dbd-plrv8 1/1 実行中 0 3分47秒 10.244.1.4 node2 <なし> <なし> 

ダッシュボードの NodePort ポートを表示します。

 ➜ ~ kubectl get svc -n kubernetes-dashboard
名前タイプ クラスター IP 外部 IP ポート 年齢
ダッシュボードメトリックスクレーパー ClusterIP 10.99.37.172 <なし> 8000/TCP 25m
 kubernetes-dashboard ノードポート 10.103.102.27 <なし> 443:31050/TCP 25 分

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

信頼証明書

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

次に、ダッシュボードにログインするためのすべてのグローバル権限を持つユーザーを作成します: (admin.yaml)

種類: ClusterRoleBinding
 apiバージョン: rbac。認証.k8s.io/v1
メタデータ:
名前:admin
ロールリファレンス:
  種類: ClusterRole
名前: クラスター管理者
  apiGroup : rbac.authorization.k8s.io
科目:
 - 種類: サービスアカウント
名前:admin
  名前空間: kubernetes-dashboard
 ---  
 APIバージョン: v1
種類: サービスアカウント
メタデータ:
名前:admin
  名前空間: 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 シークレットを取得 admin-token-lwmmx -o jsonpath={.data.token} -n kubernetes-dashboard |base64 -d
 # 非常に長いbase64文字列が生成されます

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

最後に、kubeadm を使用して、Kubernetes クラスター、coredns、ipvs、flannel、containerd の v1.22.1 バージョンの構築が完了しました。

 ➜ ~ kubectl ノードを取得 -o ワイド
名前ステータス 役割 年齢 バージョン 内部 IP 外部 IP OS イメージ カーネル バージョン コンテナ ランタイム
マスター準備完了コントロールプレーン、マスター 36m v1.22.1 192.168.31.30 <なし> CentOS Linux 7 (Core) 3.10.0-1160.25.1.el7.x86_64 containerd://1.5.5
 node2 準備完了 <なし> 27m v1.22.1 192.168.31.215 <なし> CentOS Linux 7 (Core) 3.10.0-1160.25.1.el7.x86_64 containerd://1.5.5

クリーニング

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

 ➜ ~ kubeadm リセット
➜ ~ ifconfig cni0 ダウン && ip リンク削除cni0
 ➜ ~ ifconfig flannel.1 ダウン && ip リンク削除flannel.1
 ➜ ~ rm -rf /var/lib/cni/