Kubernetes クラスターをデプロイする方法

[[339164]]

この記事はWeChatの公開アカウント「Invincible Coder」から転載したもので、著者はInvincible Coderです。この記事を転載する場合は、Wudi Coder の公開アカウントにご連絡ください。

オリジナルリンク: https://mp.weixin.qq.com/s/MFSvDWtue4YruFV3jyLQVw

この記事では、Mac ラップトップに 2 つの Ubuntu システムをインストールして、制御ノード (マスター) とコンピューティング ノード (ワーカー) を備えた Kubernetes 学習クラスターを展開する方法を説明します。

1. システム環境の準備

Kubernetes クラスターをインストールしてデプロイするには、まずマシンを準備する必要があります。最も直接的な方法は、パブリッククラウド（Alibaba Cloud など）上の複数の仮想マシンを申請することです。条件が許せば、複数のローカル物理サーバーを使用してクラスターを形成するのが最適です。ただし、これらのマシンは次の条件を満たす必要があります。

• 64 ビット Linux オペレーティング システムが必要であり、カーネル バージョンは 3.10 以上で、Docker プロジェクトのインストール要件を満たす必要があります。
• マシンはネットワーク接続を維持する必要があります。これは、コンテナ間の将来のネットワーク接続の前提条件です。
• 展開プロセス中に対応するイメージをプルする必要があるため、外部ネットワーク アクセス権が必要です。少数のイメージをここからプルする必要があるため、2 つの Docker レジストリ (gcr.io と quay.io) にアクセスできる必要があります。
• 1 台のマシンに推奨される使用可能なリソースは、2 コア CPU と 8G 以上のメモリです。より小さいサイズでも許容されますが、スケジュールできるポッドの数は制限されます。
• ディスク容量要件は 30 GB 以上で、主に Docker イメージと関連ログ ファイルを保存するために使用されます。

今回の実験では、条件が限られていたため、仮想ソフトウェアを使用して Mac ノートパソコン上に 2 台の仮想マシンを用意しました。具体的な構成は次のとおりです。

• 2 コア CPU、2GB メモリ、30GB ディスク容量。
• Unbantu 20.04 LTS サーバー バージョン、Linux カーネルは 5.4.0 です。
• イントラネットは相互接続されており、外部ネットワークのアクセス権は制御されていません。

2. Kubeadmワンクリックデプロイメントツールの紹介

典型的な分散システムである Kubernetes の導入は、初心者が Kubernetes の世界に参入する上で常に大きな障害となってきました。リリース当初、Kubernetes のデプロイメントは主にコミュニティによって管理されているさまざまなスクリプトに依存していましたが、これにはバイナリ コンパイル、構成ファイル、kube-apiserver 認証構成ファイルなどの多くの運用および保守作業が必要でした。現在、大手クラウドサービスプロバイダーが採用している一般的な Kubernetes 導入方法は、SaltStack や Ansible などの運用・保守ツールを使用して、これらの面倒な手順を自動的に実行することです。しかし、それでも、初心者にとって展開プロセスは依然として非常に面倒です。

このような問題点を踏まえ、Kubernetes コミュニティは、ボランティアの推進力により、独立したワンクリック デプロイメント ツールである kubeadm を最終的にリリースしました。 kubeadm を使用すると、いくつかの簡単な手順で Kubernetes クラスターをすばやくデプロイできます。次のコンテンツでは、kubeadm を使用して Kubernetes クラスターをデプロイする方法を具体的に説明します。

3. KubeadmとDocker環境をインストールする

準備した 2 つの仮想マシンにそれぞれ Kubeadm デプロイメント ツールと Docker 環境をインストールします。手順は次のとおりです。

1) オペレーティング システムのインストール ソース構成ファイルを編集し、Kubernetes イメージ ソースを追加します。コマンドは次のとおりです。

 #Kubernetes 公式ミラーソース apt-キーを追加 
 root@kubenetesnode01:~#curl -s https://packages.cloud.google.com/apt/doc/apt-key .gpg | apt -key で 追加-
 #Kubernetes 公式イメージソースアドレスを追加
root@kubernetesnode01:~# vim /etc/apt/sources.list
 # Kubernetesソースを追加
deb http://apt.kubernetes.io/kubernetes-xenial main

上記の操作により、kubernetes の公式イメージソースが追加されます。ネットワーク上の理由により apt.kubernetes.io にアクセスできない場合は、Alibaba Cloud イメージソース アドレスなどの国内の Ubantu イメージ ソースに置き換えることもできます。

 #Alibaba Cloud Kubernetesミラーソースapt-キーを追加 
 root@kubenetesnode01:~# curl -s https://mirrors.aliyun.com/kubernetes/apt/doc/apt-key .gpg | apt -キー 追加-
 #Alibaba Cloud Kubernetesイメージソースアドレスを追加
root@kubernetesnode01:~# vim /etc/apt/sources.list
 deb https://mirrors.aliyun.com/kubernetes/apt/kubernetes-xenial main

2) ミラーソースを追加した後、apt リソース リストを更新します。コマンドは次のとおりです。

 root@kubernetesnode01:~# apt-get update  
ヒット:1 http://cn.archive.ubuntu.com/ubuntu focused InRelease
ヒット:2 http://cn.archive.ubuntu.com/ubuntu focus-updates InRelease
ヒット:3 http://cn.archive.ubuntu.com/ubuntu focus-backports InRelease
ヒット:4 http://cn.archive.ubuntu.com/ubuntu focus-security InRelease
取得:5 https://packages.cloud.google.com/apt kubernetes-xenial InRelease [8,993 B]
取得:6 https://packages.cloud.google.com/apt kubernetes-xenial/main amd64 パッケージ [37.7 kB]
 7 秒で46.7 kB を取得(6,586 B/s)
パッケージリストを読み込んでいます...完了

3) 上記の 2 つの手順を完了したら、次のように apt-get コマンドを使用して kubeadm をインストールできます。

 root@kubernetesnode01:~# apt-get install -y docker.io kubeadm
パッケージリストを読み込んでいます...完了
依存関係ツリーの構築
状態情報を読み込んでいます...完了
次の追加パッケージがインストールされます:
 Bridge-utils cgroupfs-mount conntrack containerd cri-tools dns-root-data dnsmasq-base ebtables kubectl kubelet kubernetes-cni libidn11 pigz runc socat ubuntu-fan
 ....

ここでは、Ubantu の docker.io インストール ソースを直接使用します。上記の kubeadm のインストール プロセスでは、Kubernetes のコア コンポーネントである kubeadm と kubelet、kubectl、kubernetes-cni のバイナリ ファイルが自動的にインストールされます。

4) Dockerサービスの起動と制限の変更

上記の手順を完了すると、Docker エンジンがシステムに自動的にインストールされますが、Kubernetes デプロイメントを実行する前に、Docker 構成情報にいくつかの調整を加える必要があります。

まず、システムの /etc/default/grub ファイルを編集し、構成項目 GRUB_CMDLINE_LINUX に次のパラメータを追加します。

 GRUB_CMDLINE_LINUX= "cgroup_enable=メモリ swapaccount=1"  

編集後、以下のコマンドを保存して実行し、サーバーを再起動します。コマンドは次のとおりです。

 root@kubernetesnode01:/opt/kubernetes-config#更新-grub
 root@kubernetesnode01:/opt/kubernetes-config# 再起動

上記の変更により、主に「docker 警告 WARNING: スワップ制限がサポートされていません」という問題が解決されます。

次に、/etc/docker/daemon.json ファイルを編集して作成し、次のコンテンツを追加します。

 {
 "exec-opts" : [ "native.cgroupdriver=systemd" ]
 }

保存後、次のように Docker の再起動コマンドを実行します。

 root@kubernetesnode01:/opt/kubernetes-config# systemctl dockerを再起動します

この時点で、Docker の Cgroup 情報を次のように表示できます。

 root@kubernetesnode01:/opt/kubernetes-config# docker 情報 | grep Cグループ
 cgroup ドライバー: systemd

上記の変更により、主に「Dockercgroup ドライバー」の問題が解決されます。推奨されるドライバーは「systemd」です。上記の変更は、特定のインストール操作中に著者が遭遇した特定の問題に対する解決策にすぎないことを強調しておく必要があります。練習中に他の問題が発生した場合は、自分で関連情報を参照する必要があります。

最後に、kubernetes は仮想メモリを無効にするため、最初に swap をオフにする必要があることに注意してください。そうしないと、kubeadm が kubernetes を初期化するときに、次のようにエラーが報告されます。

 root@kubernetesnode01:/opt/kubernetes-config# swapoff -a

このコマンドはスワップを一時的に無効にするだけです。システムの再起動後も有効にするには、/etc/fstab ファイルを編集し、swap 行をコメント アウトする必要があります。

上記の操作が完了したら、システム Docker サービスを開始します。コマンドは次のとおりです。

 root@kubenetesnode02:~# systemctl で docker.service を有効にします

4. Kubernetesマスターノードをデプロイする

Kubernetes では、マスター ノードはクラスターの制御ノードです。これは、API サービスを担当する kube-apiserver、スケジューリングを担当する kube-scheduler、およびコンテナ オーケストレーションを担当する kube-controller-manager という、密接に連携する 3 つの独立したコンポーネントで構成されています。クラスター全体の永続データは kube-apiserver によって処理され、Etcd に保存されます。

マスターノードをデプロイするには、kubeadm を直接使用してワンクリックデプロイを実行することもできますが、ここでは比較的完全な Kubernetes クラスターをデプロイし、構成ファイルを通じていくつかの実験的な機能を有効にしたいと考えています。具体的には、システムに新しい /opt/kubernetes-config/ ディレクトリを作成し、kubeadm 用の YAML ファイル (kubeadm.yaml) を作成します。具体的な内容は以下のとおりです。

 APIバージョン: kubeadm.k8s.io/v1beta2
種類: ClusterConfiguration
コントローラーマネージャー:
 追加引数:
     水平ポッドオートスケーラーが REST クライアントを使用する: "true"  
     水平ポッドオートスケーラー同期期間: "10 秒"  
     ノード モニターの猶予期間: "10 秒"  
 apiサーバー:
  追加引数:
     ランタイム設定: "api/all=true"  
 kubernetesバージョン: "v1.18.1"  

上記の yaml 構成ファイルでは、構成「horizo​​ntal-pod-autoscaler-use-rest-clients: "true"」は、将来デプロイされる kuber-controller-manager が自動水平拡張のためにカスタム リソース (CustomMetrics) を使用できることを示しています。興味のある読者は、関連情報をご自身で参照してください。 「v1.18.1」は、kubeadm がデプロイを支援する Kubernetes のバージョン番号です。

なお、実行プロセス中に国内ネットワークの制限により対応する Docker イメージをダウンロードできない場合は、エラー情報に従って国内の Web サイト (Alibaba Cloud など) で関連するイメージを見つけ、インストールする前にこれらのイメージを再タグ付けすることができます。詳細は以下の通りです。

 #Alibaba Cloud DockerリポジトリからKubernetesコンポーネントイメージをプルする
docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/kube-apiserver-amd64:v1.18.1
 docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/kube-controller-manager-amd64:v1.18.1
 docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/kube-scheduler-amd64:v1.18.1
 docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/kube-proxy-amd64:v1.18.1
 docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/etcd-amd64:3.4.3-0
 docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/pause:3.2
 docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/coredns:1.6.7

ダウンロードが完了したら、これらの Docker イメージに再度タグを付けます。具体的なコマンドは以下のとおりです。

 #画像にタグを付け直す
docker タグ registry.cn-hangzhou.aliyuncs.com/google_containers/pause:3.2 k8s.gcr.io/pause:3.2
 docker タグ registry.cn-hangzhou.aliyuncs.com/google_containers/coredns:1.6.7 k8s.gcr.io/coredns:1.6.7
 docker タグ registry.cn-hangzhou.aliyuncs.com/google_containers/etcd-amd64:3.4.3-0 k8s.gcr.io/etcd:3.4.3-0
 docker タグ registry.cn-hangzhou.aliyuncs.com/google_containers/kube-scheduler-amd64:v1.18.1 k8s.gcr.io/kube-scheduler:v1.18.1
 docker タグ registry.cn-hangzhou.aliyuncs.com/google_containers/kube-controller-manager-amd64:v1.18.1 k8s.gcr.io/kube-controller-manager:v1.18.1
 docker タグ registry.cn-hangzhou.aliyuncs.com/google_containers/kube-apiserver-amd64:v1.18.1 k8s.gcr.io/kube-apiserver:v1.18.1
 docker タグ registry.cn-hangzhou.aliyuncs.com/google_containers/kube-proxy-amd64:v1.18.1 k8s.gcr.io/kube-proxy:v1.18.1

この時点で、Docker コマンドを使用して Docker イメージ情報を表示できます。コマンドは次のとおりです。

 root@kubernetesnode01:/opt/kubernetes-config# docker イメージ
リポジトリ タグ イメージ ID 作成サイズ 
 k8s.gcr.io/kube-proxy v1.18.1 4e68534e24f6 2か月前 117MB
 registry.cn-hangzhou.aliyuncs.com/google_containers/kube-proxy-amd64 v1.18.1 4e68534e24f6 2 か月前 117MB
 k8s.gcr.io/kube-controller-manager v1.18.1 d1ccdd18e6ed 2か月前 162MB
 registry.cn-hangzhou.aliyuncs.com/google_containers/kube-controller-manager-amd64 v1.18.1 d1ccdd18e6ed 2 か月前 162MB
 k8s.gcr.io/kube-apiserver v1.18.1 a595af0107f9 2か月前 173MB
 registry.cn-hangzhou.aliyuncs.com/google_containers/kube-apiserver-amd64 v1.18.1 a595af0107f9 2か月前 173MB
 k8s.gcr.io/kube-scheduler v1.18.1 6c9320041a7b 2か月前 95.3MB
 registry.cn-hangzhou.aliyuncs.com/google_containers/kube-scheduler-amd64 v1.18.1 6c9320041a7b 2 か月前 95.3MB
 k8s.gcr.io/pause 3.2 80d28bedfe5d 4か月前 683kB
 registry.cn-hangzhou.aliyuncs.com/google_containers/pause 3.2 80d28bedfe5d 4か月前 683kB
 k8s.gcr.io/coredns 1.6.7 67da37a9a360 4か月前 43.8MB
 registry.cn-hangzhou.aliyuncs.com/google_containers/coredns 1.6.7 67da37a9a360 4 か月前 43.8MB
 k8s.gcr.io/etcd 3.4.3-0 303ce5db0e90 8か月前 288MB
 registry.cn-hangzhou.aliyuncs.com/google_containers/etcd-amd64

イメージのプルの問題を解決した後、kubeadm デプロイメント コマンドを再度実行して、Kubernetes マスター コントロール ノードのデプロイメントを完了します。具体的なコマンドと実行結果は次のとおりです。

 root@kubernetesnode01:/opt/kubernetes-config# kubeadm init --config kubeadm.yaml --v=5  
 ...
 Kubernetes コントロールプレーンが正常に初期化されました。 
 
クラスターの使用を開始するには、通常のユーザーとして以下を実行する必要があります。 
 
  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config 
 
ここで、クラスターにポッド ネットワークをデプロイする必要があります。
 「kubectl apply -f [podnetwork].yaml」を実行します。  以下にリストされているオプションのいずれかを使用します。
  https://kubernetes.io/docs/concepts/cluster-administration/addons/ 
 
参加するには 任意の数のワーカーノードで、各ワーカーノードで次のコマンドをrootとして実行します。 
 
 kubeadm join 10.211.55.6:6443 --token jfulwi.so2rj5lukgsej2o6 \  
 --ディスカバリートークンCA証明書ハッシュsha256:d895d512f0df6cb7f010204193a9b240e8a394606090608daee11b988fc7fea6  

上記のデプロイメント実行結果からわかるように、デプロイメントが成功すると、kubeadm は次の指示を生成します。

 kubeadm join 10.211.55.6:6443 --token d35pz0.f50zacvbdarqn2vi \  
 --ディスカバリートークンCA証明書ハッシュsha256:58958a3bf4ccf4a4c19b0d1e934e77bf5b5561988c2274364aaadc9b1747141d  

kubeadm join コマンドは、マスター ノードにワーカーを追加するために使用されます。これは、後でワーカー ノードをデプロイするときに使用されます。さらに、kubeadm は、Kubernetes クラスターを初めて使用するときに設定する必要があるコマンドの入力も求めます。

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

これらの構成コマンドが必要な理由は、Kubernetes クラスターではデフォルトで暗号化されたアクセスが必要なため、これらのコマンドは、デプロイされたばかりの Kubernetes クラスターのセキュリティ構成ファイルを現在のユーザーの .kube ディレクトリに保存するためです。その後、kubectl はデフォルトでこのディレクトリ内の認証情報を使用して Kubernetes クラスターにアクセスします。これを行わない場合は、クラスターを渡すたびに「export KUBE CONFIG 環境変数」を設定して、kubectl にセキュリティ ファイルの場所を伝える必要があります。

上記のコマンドを実行した後、kubectlget コマンドを使用して現在の Kubernetes クラスター ノードのステータスを表示できるようになります。実行効果は以下のとおりです。

 root@kubernetesnode01:/opt/kubernetes-config# kubectl ノードを取得します
名前ステータス 役割 年齢 バージョン
kubernetesnode01 NotReady マスター 35m v1.18.4

上記のコマンドの出力では、マスター ノードのステータスが「NotReady」であることがわかります。具体的な理由を見つけるには、「kuberctl describe」コマンドを使用してノード オブジェクトの詳細情報を表示します。コマンドは次のとおりです。

 root@kubernetesnode01:/opt/kubernetes-config# kubectl ノード kubernetesnode01 を記述します

このコマンドは、ノード オブジェクトのステータス、イベント、その他の詳細を詳細に取得できます。この方法は、Kubernetes クラスターをデバッグする際の最も重要なトラブルシューティング方法でもあります。以下の情報によると:

 ...
条件
...
準備完了False ... KubeletNotReady ランタイムネットワークの準備ができていません: NetworkReady= false理由:NetworkPluginNotReady メッセージ:docker: ネットワークプラグインは 準備ができていません: cni 構成が初期化されていません
...

ノードが「NodeNotReady」状態になっている理由は、ネットワーク プラグインがデプロイされていないためであることがわかります。この点をさらに検証するには、kubectl を使用して、このノード上の各 Kubernetes システム Pod のステータスを確認することもできます。コマンドと実行効果は次のとおりです。

 root@kubernetesnode01:/opt/kubernetes-config# kubectl get pods -n kube-system
名前準備完了 ステータス 再起動 年齢
coredns-66bff467f8-l4wt6 0/1 保留中 0 64分
coredns-66bff467f8-rcqx6 0/1 保留中 0 64分
etcd-kubernetesnode01 1/1 実行中 0 64分
kube-apiserver-kubernetesnode01 1/1 実行中 0 64 分
kube-controller-manager-kubernetesnode01 1/1 実行中 0 64分
kube-proxy-wjct7 1/1 実行中 0 64分
kube-scheduler-kubernetesnode01 1/1 実行中 0 64分

コマンドでは、「kube-system」は Kubernetes プロジェクト用に予約されたシステム Pod スペース (名前空間) を指します。これは Linux 名前空間ではなく、Kuebernetes によって分割された異なるワークスペース ユニットであることに注意してください。コマンド出力に戻ると、coredns およびその他のネットワーク依存の Pod が Pending (スケジュール失敗) 状態にあることがわかります。これは、マスター ノードのネットワークがまだデプロイの準備ができていないことを意味します。

5. Kubernetesネットワークプラグインをデプロイする

マスター ノードの以前の展開では、ネットワーク プラグインが展開されていなかったため、ノードのステータスは「NodeNotReady」と表示されます。次のコンテンツでは、ネットワーク プラグインを詳細に展開します。 Kubernetes の「すべてがコンテナ」という設計コンセプトの指針に従い、ネットワーク プラグインも独立した Pod としてシステム内で実行されるため、展開も非常に簡単です。 「kubectl apply」コマンドを実行するだけです。たとえば、Weave ネットワーク プラグインを例に挙げます。

 root@kubernetesnode01:/opt/kubernetes-config# kubectl apply -f https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n' )
 serviceaccount/weave-net が作成されました
clusterrole.rbac。認証.k8s.io/weave-net が作成されました
クラスターロールバインディング.rbac。認証.k8s.io/weave-net が作成されました
ロール.rbac。認証.k8s.io/weave-net が作成されました
ロールバインディング.rbac。認証.k8s.io/weave-net が作成されました
daemonset.apps/weave-net が作成されました

デプロイが完了したら、「kubectl get」コマンドを使用してポッドのステータスを再確認します。

 root@kubernetesnode01:/opt/kubernetes-config# kubectl get pods -n kube-system
名前準備完了 ステータス 再起動 年齢
coredns-66bff467f8-l4wt6 1/1 ランニング 0 116m
 coredns-66bff467f8-rcqx6 1/1 実行中 0 116m
 etcd-kubernetesnode01 1/1 実行中 0 116分
kube-apiserver-kubernetesnode01 1/1 実行中 0 116分
kube-controller-manager-kubernetesnode01 1/1 実行中 0 116分
kube-proxy-wjct7 1/1 実行中 0 116分
kube-scheduler-kubernetesnode01 1/1 実行中 0 116分
織りネット746qj

この時点ですべてのシステム Pod が正常に起動され、デプロイされたばかりの Weave ネットワーク プラグインによって kube-system の下に「weave-net-746qj」という名前の新しい Pod が作成されたことがわかります。この Pod は、各ノード上のコンテナ ネットワーク プラグインの制御コンポーネントです。

この時点で、Kubernetes マスター ノードがデプロイされています。単一ノードの Kubernetes のみが必要な場合は、今すぐ使用できます。ただし、デフォルトでは、Kubernetes マスターノードはユーザー Pod を実行できないため、追加の操作を通じて調整する必要があります。興味のある友人は自分で他の情報を確認することができます。

6. Kubernetesワーカーノードをデプロイする

完全な Kubernetes クラスターを構築するには、ワーカー ノードをデプロイする方法を引き続き紹介する必要があります。実は、Kubernetes のワーカーノードとマスターノードはほぼ同じです。どちらも kubelet コンポーネントを実行します。主な違いは、「kubeadm init」プロセス中に、kubelet が起動された後、マスターノードが 3 つのシステムポッド (kube-apiserver、kube-scheduler、および kube-controller-manager) を自動的に起動することです。

特定のデプロイメントの前に、マスター ノードと同様に、すべてのワーカー ノードで、前の「kubeadm と Decker 環境のインストール」セクションのすべての手順を実行する必要があります。次に、マスターノードをワーカーノードにデプロイするときに生成された「kubeadm join」コマンドを次のように実行します。

 root@kubenetesnode02:~# kubeadm join 10.211.55.6:6443 --token jfulwi.so2rj5lukgsej2o6 --discovery-token-ca-cert-hash sha256:d895d512f0df6cb7f010204193a9b240e8a394606090608daee11b988fc7fea6 --v=5   
 
 ...
このノードはクラスターに参加しました:
 * 証明書署名要求がapiserverに送信され、応答が受信されました。
 * Kubelet に新しい安全な接続の詳細が通知されました。 
 
 「kubectl get nodes」を実行します コントロールプレーンでこのノードがクラスターに参加することを確認します。

クラスターに参加した後、ワーカー ノードで kubectl 関連のコマンドを実行するには、次の構成が必要です。

 #設定ディレクトリを作成する
root@kubenetesnode02:~# mkdir -p $HOME/.kube
 #マスターノードの$/HOME/.kube/ディレクトリにある設定ファイルをワーカーノードの対応するディレクトリにコピーします
root@kubenetesnode02:~# scp [email protected]:$HOME/.kube/config $HOME/.kube/
 #権限設定
root@kubenetesnode02:~# sudo chown $(id -u):$(id -g) $HOME/.kube/config

次に、次のように、ワーカー ノードまたはマスター ノードでノード ステータス チェック コマンド「kubectl get nodes」を実行できます。

 root@kubernetesnode02:~# kubectl ノードを取得します
名前ステータス 役割 年齢 バージョン
kubenetesnode02 NotReady <なし> 33 分 v1.18.4
 kubernetesnode01 マスター 29h v1.18.4 準備完了

ノード ステータスには、Work ノードがまだ NotReady 状態であることが示されています。具体的なノード記述情報は次のとおりです。

 root@kubernetesnode02:~# kubectl ノード kubenetesnode02 を記述します
...
条件：
 ...
準備完了False ... KubeletNotReady ランタイムネットワークの準備ができていません: NetworkReady= false理由:NetworkPluginNotReady メッセージ:docker: ネットワークプラグインは 準備ができていません: cni 構成が初期化されていません
...

説明情報によると、Worker ノードが NotReady である理由は、ネットワーク プラグインがデプロイされていないためです。 「Kubernetes ネットワーク プラグインのデプロイ」セクションの手順を続行します。ただし、ネットワーク プラグインをデプロイすると、kube-proxy も同時にデプロイされ、k8s.gcr.io ウェアハウスからイメージを取得することになるので注意してください。外部ネットワークにアクセスできない場合は、ネットワークの展開に異常がある可能性があります。ここでは、マスターノードをインストールする以前の方法を参照できます。国内の画像倉庫からダウンロードした後、以下のようにタグを付けます。

 root@kubenetesnode02:~# docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/kube-proxy-amd64:v1.18.1
 root@kubenetesnode02:~# docker タグ registry.cn-hangzhou.aliyuncs.com/google_containers/kube-proxy-amd64:v1.18.1 k8s.gcr.io/kube-proxy:v1.18.1

すべてが正常であれば、ノードのステータスの確認を続けます。コマンドは次のとおりです。

 root@kubenetesnode02:~# kubectl ノードの取得
名前ステータス 役割 年齢 バージョン
kubenetesnode02 準備完了 <なし> 7 時間 52 分 v1.18.4
 kubernetesnode01 マスター 37h v1.18.4 準備完了

ワーカーノードのステータスが「準備完了」に変わったことがわかります。しかし、注意深い読者は、ワーカーノードのROLESがマスターノードのように「マスター」ではなく、これは、新しくインストールされた Kubernetes 環境のノードが ROLES 情報を失うことがあるためです。この場合は手動で追加できます。具体的なコマンドは以下のとおりです。

 root@kubenetesnode02:~# kubectl ラベル ノード kubenetesnode02 node-role.kubernetes.io/worker=worker

ノード ステータス コマンドを再度実行して、通常の表示を確認します。コマンドの効果は次のとおりです。

 root@kubenetesnode02:~# kubectl ノードの取得
名前ステータス 役割 年齢 バージョン
kubenetesnode02 レディワーカー 8h v1.18.4
 kubernetesnode01 マスター 37h v1.18.4 準備完了

この時点で、マスター ノードとワーカー ノードを含む Kubernetes クラスターがデプロイされています。実験環境としては、基本的なKubernetesクラスタ機能がすでに備わっています！

7. ダッシュボード可視化プラグインを導入する

Kubernetes コミュニティには、現在のクラスター内のさまざまな情報を表示するための視覚的な Web インターフェースをユーザーに提供する人気のダッシュボード プロジェクトがあります。プラグインもコンテナ化されてデプロイされており、操作も非常に簡単です。マスターノード、ワーカーノード、または Kubernetes クラスターに安全にアクセスできるその他のノードにデプロイできます。コマンドは次のとおりです。

 root@kubenetesnode02:~# kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.3/aio/deploy/recommended.yaml

デプロイが完了すると、ダッシュボードに対応するポッドの実行ステータスを表示できます。実行効果は以下のとおりです。

 root@kubenetesnode02:~# kubectl get pods -n kubernetes-dashboard
名前準備完了 ステータス 再起動 年齢
dashboard-metrics-scraper-6b4884c9d5-xfb8b 1/1 実行中 0 12h
 kubernetes-dashboard-7f99b75bf4-9lxk8 1/1 実行中 0 12時間

また、ダッシュボードのサービス情報も閲覧できます。コマンドは次のとおりです。

 root@kubenetesnode02:~# kubectl get svc -n kubernetes-dashboard
名前タイプ クラスター IP 外部 IP ポート 年齢
ダッシュボードメトリックスクレーパー ClusterIP 10.97.69.158 <なし> 8000/TCP 13h
 kubernetes-dashboard クラスターIP 10.111.30.214 <なし> 443/TCP 13h

ダッシュボードは Web サービスであるため、セキュリティの観点から、デフォルトではプロキシ経由でのみローカルにダッシュボードにアクセスできることに注意してください。具体的な方法は、ローカル マシンに kubectl 管理ツールをインストールし、マスター ノードの $HOME/.kube/ ディレクトリにある構成ファイルをローカル ホストの同じディレクトリにコピーして、次のように「kubectl proxy」コマンドを実行することです。

 qiaodeMacBook-Pro-2:.kube qiaojiang$ kubectl プロキシ
127.0.0.1:8001でサービスを開始

ローカル プロキシが起動したら、次のように Kubernetes ダッシュボード アドレスにアクセスします。

 http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/

アクセスが正常であれば、対応するインターフェースが表示されます。上記は、基本的な Kubernetes クラスターを構築する方法です。 Kubernetes コンテナ オーケストレーション テクノロジーの学習に役立つことを願っています。