これは、このセクションの複数ページの印刷可能なビューです。 印刷するには、ここをクリックしてください.
クラスターの管理
- 1: kubeadmによる管理
- 1.1: Linuxワーカーノードの追加
- 1.2: cgroupドライバーの設定
- 1.3: kubeadmクラスターのアップグレード
- 1.4: Windowsノードの追加
- 1.5: Linuxノードのアップグレード
- 1.6: Windowsノードのアップグレード
- 1.7: kubeadmによる証明書管理
- 2: dockershimからの移行
- 2.1: ノードのコンテナランタイムをDocker Engineからcontainerdに変更する
- 2.2: ノードで使用されているコンテナランタイムの確認
- 2.3: dockershim削除の影響範囲を確認する
- 2.4: dockershimからテレメトリーやセキュリティエージェントを移行する
- 3: 証明書を手動で生成する
- 4: メモリー、CPU、APIリソースの管理
- 4.1: Namespaceのデフォルトのメモリ要求と制限を設定する
- 4.2: Namespaceに対する最小および最大メモリー制約の構成
- 4.3: Namespaceの最小および最大CPU制約を設定する
- 4.4: NamespaceのメモリおよびCPUクォータを設定する
- 4.5: NamespaceのPodクォータを設定する
- 5: ネットワークポリシープロバイダーのインストール
- 6: Kubernetes APIを使用してクラスターにアクセスする
- 7: フィーチャーゲートの有効化または無効化
- 8: 拡張リソースをNodeにアドバタイズする
- 9: クラスター内のDNSサービスのオートスケール
- 10: デフォルトのStorageClassを変更する
- 11: クラウドコントローラーマネージャーの運用管理
- 12: kubelet image credential providerの設定
- 13: ノードのトポロジー管理ポリシーを制御する
- 14: DNS解決のデバッグ
- 15: ネットワークポリシーを宣言する
- 16: クラウドコントローラーマネージャーの開発
- 17: Kubernetes APIの有効化または無効化
- 18: 保存時に既に暗号化されている機密データを復号する
- 19: 重要なアドオンPodに対するスケジューリングの保証
- 20: ストレージの消費を制限する
- 21: Kubernetes向けetcdクラスターの運用
- 22: ノードを安全にドレインする
- 23: クラスターのセキュリティ
- 24: 名前空間を使用してクラスターを共有する
- 25: クラスターのアップグレード
- 26: クラスターでカスケード削除を使用する
- 27: データ暗号化にKMSプロバイダーを使用する
- 28: サービスディスカバリーにCoreDNSを使用する
- 29: KubernetesクラスターでNodeLocal DNSキャッシュを使用する
- 30: EndpointSliceの有効化
1 - kubeadmによる管理
1.1 - Linuxワーカーノードの追加
このページでは、kubeadmクラスターにLinuxワーカーノードを追加する方法を示します。
始める前に
- ワーカーノードとして追加する各マシンに、kubeadmのインストールで要求されている、kubeadm、kubelet、コンテナランタイム等のコンポーネントがインストールされていること。
kubeadm initで構築され、kubeadmを使用したクラスターの作成ドキュメントの手順に従った稼働中のkubeadmクラスターが存在すること。- ノードにスーパーユーザー権限でアクセスできること。
Linuxワーカーノードの追加
新たなLinuxワーカーノードをクラスターに追加するために、以下を各マシンに対して実行してください。
- SSH等の手段でマシンへ接続します。
kubeadm init実行時に出力されたコマンドを実行します。例:
sudo kubeadm join --token <token> <control-plane-host>:<control-plane-port> --discovery-token-ca-cert-hash sha256:<hash>
kubeadm joinに関する追加情報
備考:
<control-plane-host>:<control-plane-port>にIPv6タプルを指定するには、IPv6アドレスを角括弧で囲みます。
例: [2001:db8::101]:2073トークンが不明な場合は、コントロールプレーンノードで次のコマンドを実行すると取得できます。
# コントロールプレーンノード上で実行してください。
sudo kubeadm token list
出力は次のようになります。
TOKEN TTL EXPIRES USAGES DESCRIPTION EXTRA GROUPS
8ewj1p.9r9hcjoqgajrj4gi 23h 2018-06-12T02:51:28Z authentication, The default bootstrap system:
signing token generated by bootstrappers:
'kubeadm init'. kubeadm:
default-node-token
デフォルトでは、トークンは24時間後に有効期限が切れます。 現在のトークンの有効期限が切れた後にクラスターにノードを参加させたい場合は、コントロールプレーンノード上で次のコマンドを実行することで、新しいトークンを生成できます。
# コントロールプレーンノード上で実行してください。
sudo kubeadm token create
このコマンドの出力は次のようになります。
5didvk.d09sbcov8ph2amjw
新たなトークンを生成しながらkubeadm joinコマンドを出力するには、次のコマンドを使用します。
sudo kubeadm token create --print-join-command
--discovery-token-ca-cert-hashの値が不明な場合は、コントロールプレーンノード上で次のコマンドを実行することで取得できます。
# コントロールプレーンノード上で実行してください。
sudo cat /etc/kubernetes/pki/ca.crt | openssl x509 -pubkey | openssl rsa -pubin -outform der 2>/dev/null | \
openssl dgst -sha256 -hex | sed 's/^.* //'
出力は次のようになります。
8cb2de97839780a412b93877f8507ad6c94f73add17d5d7058e91741c9d5ec78
kubeadm joinコマンドによって以下のように出力されるはずです。
[preflight] Running pre-flight checks
... (log output of join workflow) ...
Node join complete:
* Certificate signing request sent to control-plane and response
received.
* Kubelet informed of new secure connection details.
Run 'kubectl get nodes' on control-plane to see this machine join.
数秒後、kubectl get nodesを実行すると、出力内にこのノードが表示されるはずです(kubectlコマンドは、コントロールプレーンノード等で実行してください)。
備考:
クラスターのノードは、通常は順番に初期化されるため、CoreDNSのPodは全て最初のコントロールプレーンノードで実行されている可能性があります。 高可用性を実現するため、新たなノードを追加した後にはkubectl -n kube-system rollout restart deployment corednsコマンドを実行してCoreDNSのPodを再配置してください。次の項目
- Windowsワーカーノードを追加する方法を参照してください。
1.2 - cgroupドライバーの設定
このページでは、kubeadmクラスターのコンテナランタイムcgroupドライバーに合わせて、kubelet cgroupドライバーを設定する方法について説明します。
始める前に
Kubernetesのコンテナランタイムの要件を熟知している必要があります。
コンテナランタイムのcgroupドライバーの設定
コンテナランタイムページでは、kubeadmベースのセットアップではcgroupfsドライバーではなく、systemdドライバーが推奨されると説明されています。
このページでは、デフォルトのsystemdドライバーを使用して多くの異なるコンテナランタイムをセットアップする方法についての詳細も説明されています。
kubelet cgroupドライバーの設定
kubeadmでは、kubeadm initの際にKubeletConfiguration構造体を渡すことができます。
このKubeletConfigurationには、kubeletのcgroupドライバーを制御するcgroupDriverフィールドを含めることができます。
備考:
v1.22では、ユーザーがKubeletConfigurationのcgroupDriverフィールドを設定していない場合、kubeadmはデフォルトでsystemdを設定するようになりました。フィールドを明示的に設定する最小限の例です:
# kubeadm-config.yaml
kind: ClusterConfiguration
apiVersion: kubeadm.k8s.io/v1beta3
kubernetesVersion: v1.21.0
---
kind: KubeletConfiguration
apiVersion: kubelet.config.k8s.io/v1beta1
cgroupDriver: systemd
このような設定ファイルは、kubeadmコマンドに渡すことができます:
kubeadm init --config kubeadm-config.yaml
備考:
Kubeadmはクラスター内の全ノードで同じKubeletConfigurationを使用します。
KubeletConfigurationはkube-system名前空間下のConfigMapオブジェクトに格納されます。
サブコマンドinit、join、upgradeを実行すると、kubeadmがKubeletConfigurationを/var/lib/kubelet/config.yaml以下にファイルとして書き込み、ローカルノードのkubeletに渡します。
cgroupfsドライバーの使用
このガイドで説明するように、cgroupfsドライバーをkubeadmと一緒に使用することは推奨されません。
cgroupfsを使い続け、kubeadm upgradeが既存のセットアップでKubeletConfiguration cgroupドライバーを変更しないようにするには、その値を明示的に指定する必要があります。
これは、将来のバージョンのkubeadmにsystemdドライバーをデフォルトで適用させたくない場合に適用されます。
値を明示する方法については、後述の「kubelet ConfigMapの修正」の項を参照してください。
cgroupfsドライバーを使用するようにコンテナランタイムを設定したい場合は、選択したコンテナランタイムのドキュメントを参照する必要があります。
systemdドライバーへの移行
既存のkubeadmクラスターのcgroupドライバーをsystemdにインプレースで変更する場合は、kubeletのアップグレードと同様の手順が必要です。
これには、以下に示す両方の手順を含める必要があります。
備考:
あるいは、クラスター内の古いノードをsystemdドライバーを使用する新しいノードに置き換えることも可能です。
この場合、新しいノードに参加する前に以下の最初のステップのみを実行し、古いノードを削除する前にワークロードが新しいノードに安全に移動できることを確認する必要があります。kubelet ConfigMapの修正
kubectl get cm -n kube-system | grep kubelet-configで、kubelet ConfigMapの名前を探します。kubectl edit cm kubelet-config-x.yy -n kube-systemを呼び出します(x.yyはKubernetesのバージョンに置き換えてください)。- 既存の
cgroupDriverの値を修正するか、以下のような新しいフィールドを追加します。
cgroupDriver: systemd
このフィールドは、ConfigMapのkubelet:セクションの下に存在する必要があります。
全ノードでcgroupドライバーを更新
クラスター内の各ノードについて:
- Drain the nodeを
kubectl drain <node-name> --ignore-daemonsetsを使ってドレーンします。 systemctl stop kubeletを使用して、kubeletを停止します。- コンテナランタイムの停止。
- コンテナランタイムのcgroupドライバーを
systemdに変更します。 var/lib/kubelet/config.yamlにcgroupDriver: systemdを設定します。- コンテナランタイムの開始。
systemctl start kubeletでkubeletを起動します。- Drain the nodeを
kubectl uncordon <node-name>を使って行います。
ワークロードが異なるノードでスケジュールするための十分な時間を確保するために、これらのステップを1つずつノード上で実行します。 プロセスが完了したら、すべてのノードとワークロードが健全であることを確認します。
1.3 - kubeadmクラスターのアップグレード
このページでは、kubeadmで作成したKubernetesクラスターをバージョン1.36.xから1.37.xに、または1.37.xから1.37.y(y > x)にアップグレードする方法を説明します。 マイナーバージョンを飛ばしてのアップグレードはサポートされていません。 詳細はバージョンスキューポリシーを参照してください。
古いバージョンのkubeadmで作成したクラスターのアップグレードについては、次のページを参照してください。
- 1.35から1.36へのkubeadmクラスターのアップグレード
- 1.34から1.35へのkubeadmクラスターのアップグレード
- 1.33から1.34へのkubeadmクラスターのアップグレード
- 1.32から1.33へのkubeadmクラスターのアップグレード
Kubernetesプロジェクトでは最新のパッチリリースへの早めのアップグレードと、サポート対象のマイナーリリースを実行することを推奨しています。 これによりセキュリティを維持できます。
アップグレードの大まかなワークフローは次の通りです。
- プライマリコントロールプレーンノードをアップグレードする。
- 追加のコントロールプレーンノードをアップグレードする。
- ワーカーノードをアップグレードする。
始める前に
- リリースノートをよく確認してください。
- クラスターは静的コントロールプレーンとetcd Pod、または外部etcdを使用している必要があります。
- データベースに保存されたアプリケーションレベルの状態など、重要なコンポーネントのバックアップを取ってください。
kubeadm upgradeはワークロードには触れず、Kubernetes内部のコンポーネントのみを対象としますが、バックアップは常に推奨されます。 - Swapを無効にする必要があります。
追加情報
- 以下の手順は、アップグレード中にいつノードをドレインするかの目安を示しています。 kubeletのマイナーバージョンアップグレードを行う場合、対象ノードは事前にドレインする必要があります。 コントロールプレーンノードの場合、CoreDNS Podや他の重要なワークロードが実行されている可能性があります。 詳しくはノードのドレインを参照してください。
- Kubernetesプロジェクトではkubeletとkubeadmのバージョンを合わせることを推奨しています。 kubeadmより古いkubeletを使うことは可能ですが、サポートされているバージョン範囲内である必要があります。 詳細はkubeletに対するkubeadmのバージョンの差異を参照してください。
- アップグレード後はすべてのコンテナが再起動されます。 これはコンテナのハッシュ値が変わるためです。
- kubeletのアップグレード後にkubeletサービスが正常に再起動したことを確認するには、
systemctl status kubeletを実行するか、journalctl -xeu kubeletでサービスログを確認できます。 kubeadm upgradeは--configフラグでUpgradeConfigurationAPI typeを受け付けます。 これによりアップグレードプロセスを構成できます。kubeadm upgradeは既存クラスターの再構成をサポートしません。 既存クラスターの再構成についてはkubeadmクラスターの再構成の手順に従ってください。
etcdのアップグレードに関する考慮事項
kube-apiserverのStatic Podは(ノードをドレインしていても)常に実行されているため、etcdのアップグレードを含むkubeadmアップグレードを実行すると、新しいetcd Static Podが再起動している間にサーバーへの処理中のリクエストが停滞する可能性があります。
回避策として、kubeadm upgrade applyコマンドを開始する数秒前にkube-apiserverプロセスを一時的に停止することが可能です。
こうすることで処理中のリクエストを完了させ、既存接続をクローズでき、etcdのダウンタイムの影響を最小限にできます。
コントロールプレーンノードでは次のように行います。
killall -s SIGTERM kube-apiserver # kube-apiserverのグレースフルシャットダウンをトリガーする
sleep 20 # 処理中のリクエストの完了まで少し待つ
kubeadm upgrade ... # kubeadm upgradeコマンドを実行
パッケージリポジトリの変更
- コミュニティが運営するパッケージリポジトリ(
pkgs.k8s.io)を使用している場合、目的のKubernetesマイナーリリース向けにパッケージリポジトリを有効にする必要があります。 詳しくはKubernetesパッケージリポジトリの変更を参照してください。
apt.kubernetes.ioおよびyum.kubernetes.io)は2023年9月13日以降、非推奨となり凍結されています。
pkgs.k8s.ioにてホストされている新しいリポジトリの使用が強く推奨されており、2023年9月13日以降にリリースされたKubernetesのバージョンをインストールするには必須となっています。
非推奨の古いリポジトリとその内容は、将来事前予告なく削除される可能性があります。
新しいパッケージリポジトリでは、v1.24.0以降のKubernetesバージョンのダウンロードを提供しています。アップグレード先バージョンを決定する
OSのパッケージマネージャーを使って、Kubernetes 1.37の最新パッチを見つけます。
# リスト内の最新の1.37バージョンを探します。
# 形式は1.37.x-*のようになります。
sudo apt update
sudo apt-cache madison kubeadm
DNFを使うシステム:
# リスト内の最新の1.37バージョンを探します。
# 形式は1.37.x-*のようになります。
sudo yum list --showduplicates kubeadm --disableexcludes=kubernetes
DNF5を使うシステム:
# リスト内の最新の1.37バージョンを探します。
# 形式は1.37.x-*のようになります。
sudo yum list --showduplicates kubeadm --setopt=disable_excludes=kubernetes
期待するバージョンが表示されない場合は、Kubernetesパッケージリポジトリが利用されているか確認してください。
コントロールプレーンノードのアップグレード
コントロールプレーンノードのアップグレードはノードごとに順に実行する必要があります。
まずアップグレードするコントロールプレーンノードを選んでください。
そのノードには/etc/kubernetes/admin.confファイルが存在する必要があります。
"kubeadm upgrade"の実行
最初のコントロールプレーンノードの場合
kubeadmをアップグレードします。
# 1.37.x-*のxを、今回のアップグレードで選んだ最新パッチに置き換えてください sudo apt-mark unhold kubeadm && \ sudo apt-get update && sudo apt-get install -y kubeadm='1.37.x-*' && \ sudo apt-mark hold kubeadmDNFを使うシステム:
# 1.37.x-*のxを、今回のアップグレードで選んだ最新パッチに置き換えてください sudo yum install -y kubeadm-'1.37.x-*' --disableexcludes=kubernetesDNF5を使うシステム:
# 1.37.x-*のxを、今回のアップグレードで選んだ最新パッチに置き換えてください sudo yum install -y kubeadm-'1.37.x-*' --setopt=disable_excludes=kubernetesダウンロードが期待したバージョンであることを確認します。
kubeadm versionアップグレードプランを確認します。
sudo kubeadm upgrade planこのコマンドはクラスターがアップグレード可能かどうかをチェックし、アップグレードできるバージョンを取得します。 また、コンポーネント設定のバージョン状態を示すテーブルも表示します。
備考:
kubeadm upgradeはこのノードで管理している証明書の更新も自動で行います。 証明書更新を無効にするには--certificate-renewal=falseフラグを使用できます。 証明書管理の詳細はkubeadmによる証明書管理を参照してください。アップグレードするバージョンを選び、適切なコマンドを実行します。 例えば:
# 今回選んだパッチバージョンでxを置き換えてください sudo kubeadm upgrade apply v1.37.xコマンドが終了すると、次のようなメッセージが表示されます。
[upgrade/successful] SUCCESS! Your cluster was upgraded to "v1.37.x". Enjoy! [upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so.備考:
v1.28より前のバージョンでは、kubeadmは他のコントロールプレーンインスタンスがアップグレードされていない場合でも、kubeadm upgrade apply実行中にアドオン(CoreDNSやkube-proxyを含む)を直ちにアップグレードするモードがデフォルトでした。 これは互換性の問題を引き起こす可能性があります。 v1.28以降、kubeadmは全てのコントロールプレーンインスタンスがアップグレードされているかを確認してから、アドオンのアップグレードを開始するモードをデフォルトにしています。 コントロールプレーンインスタンスは順次アップグレードするか、最後のインスタンスのアップグレードを他のインスタンスの完了まで開始しないようにしてください。 アドオンのアップグレードは、最後のコントロールプレーンインスタンスがアップグレードされた後に行われます。CNIプロバイダーのプラグインを手動でアップグレードします。
コンテナネットワークインターフェース(CNI)プロバイダーは、独自のアップグレード手順を持つ場合があります。 アドオンのページで使用しているCNIプロバイダーを確認し、追加のアップグレード手順が必要かどうかを確認してください。
なお、CNIプラグインがDaemonSetで動作している場合、追加のコントロールプレーンノードではこの手順は不要です。
他のコントロールプレーンノードの場合
最初のコントロールプレーンノードと同様の手順ですが、
sudo kubeadm upgrade apply
の代わりに、
sudo kubeadm upgrade node
を使用します。
また、kubeadm upgrade planの実行やCNIプラグインのアップグレードは不要です。
ノードのドレイン
メンテナンス準備として、ノードをスケジューリング不可にしてワークロードを退避させます。
# <node-to-drain>をドレインするノード名に置き換えてください
kubectl drain <node-to-drain> --ignore-daemonsets
kubeletとkubectlのアップグレード
kubeletとkubectlをアップグレードします。
# 1.37.x-*のxを、今回のアップグレードで選んだ最新パッチに置き換えてください sudo apt-mark unhold kubelet kubectl && \ sudo apt-get update && sudo apt-get install -y kubelet='1.37.x-*' kubectl='1.37.x-*' && \ sudo apt-mark hold kubelet kubectlDNFを使うシステム:
# 1.37.x-*のxを、今回のアップグレードで選んだ最新パッチに置き換えてください sudo yum install -y kubelet-'1.37.x-*' kubectl-'1.37.x-*' --disableexcludes=kubernetesDNF5を使うシステム:
# 1.37.x-*のxを、今回のアップグレードで選んだ最新パッチに置き換えてください sudo yum install -y kubelet-'1.37.x-*' kubectl-'1.37.x-*' --setopt=disable_excludes=kuberneteskubeletを再起動します。
sudo systemctl daemon-reload sudo systemctl restart kubelet
ノードのuncordon(スケジュール可能化)
ノードを再びスケジュール可能にしてオンラインにします。
# <node-to-uncordon>を対象ノード名に置き換えてください
kubectl uncordon <node-to-uncordon>
ワーカーノードのアップグレード
ワーカーノードのアップグレードは、ワークロードを実行するための必要最小限の容量を損なわない範囲で、ノードを1台ずつまたは複数台ずつ順に実行してください。
LinuxとWindowsのワーカーノードのアップグレード方法については次のページを参照してください。
クラスターの状態を確認する
kubeletをすべてのノードでアップグレードした後、kubectlがクラスターにアクセス可能な場所から以下のコマンドを実行し、すべてのノードが再び利用可能であることを確認してください。
kubectl get nodes
STATUS列にはすべてのノードでReadyが表示され、バージョン番号が更新されているはずです。
障害状態からの復旧
kubeadm upgradeが失敗してロールバックしない場合(例えば実行中の予期しないシャットダウンなど)、再度kubeadm upgradeを実行することで回復できます。
kubeadm upgradeは冪等性があり、最終的に実際の状態が宣言した望ましい状態であることを保証します。
悪い状態から回復するため、クラスターが実行しているバージョンを変更せずにsudo kubeadm upgrade apply --forceを実行することもできます。
アップグレード中、kubeadmは/etc/kubernetes/tmp配下に、次のバックアップフォルダーを書き込みます。
kubeadm-backup-etcd-<date>-<time>kubeadm-backup-manifests-<date>-<time>
kubeadm-backup-etcdには、このコントロールプレーンノードのローカルetcdメンバーデータのバックアップが含まれます。
etcdのアップグレードに失敗し、自動ロールバックが機能しない場合、このフォルダーの内容を/var/lib/etcdに手動で復元できます。
外部etcdを使用している場合、このバックアップフォルダーは空になります。
kubeadm-backup-manifestsには、このコントロールプレーンノードのStatic Podマニフェストファイルのバックアップが含まれます。
アップグレードの失敗や自動ロールバックが機能しない場合、このフォルダーの内容を/etc/kubernetes/manifestsに手動で復元できます。
何らかの理由で特定のコンポーネントのアップグレード前とアップグレード後のマニフェストに差分がない場合、そのコンポーネントのバックアップファイルは書き込まれません。
備考:
kubeadmを使ったクラスターのアップグレード後、バックアップディレクトリ/etc/kubernetes/tmpは残り、これらのバックアップファイルは手動で削除する必要があります。動作の仕組み
kubeadm upgrade applyは次のことを行います。
- クラスターがアップグレード可能な状態であることをチェックする。
- APIサーバーに到達可能であること
- すべてのノードが
Ready状態であること - コントロールプレーンが健全であること
- バージョンスキューポリシーを適用する。
- コントロールプレーンのイメージが利用可能であるか、あるいはマシンに取得可能であることを確認する。
- コンポーネント設定がバージョンアップを必要とする場合、代替を生成する、またはユーザー提供の上書きを使用する、あるいはその両方を行う。
- コントロールプレーンコンポーネントをアップグレードし、いずれかが起動しない場合はロールバックする。
- 新しい
CoreDNSとkube-proxyマニフェストを適用し、必要なすべてのRBACルールが作成されていることを確認する。 - APIサーバーの新しい証明書とキーファイルを作成し、期限が180日以内に切れる場合は古いファイルをバックアップする。
kubeadm upgrade nodeは追加のコントロールプレーンノードで次のことを行います。
- kubeadmの
ClusterConfigurationをクラスターから取得する。 - オプションでkube-apiserverの証明書をバックアップする。
- コントロールプレーンコンポーネントのStatic Podマニフェストをアップグレードする。
- このノードのkubelet設定をアップグレードする。
kubeadm upgrade nodeはワーカーノードで次のことを行います。
- kubeadmの
ClusterConfigurationをクラスターから取得する。 - このノードのkubelet設定をアップグレードする。
1.4 - Windowsノードの追加
Kubernetesを使用してLinuxノードとWindowsノードを混在させて実行できるため、Linuxで実行するPodとWindowsで実行するPodを混在させることができます。このページでは、Windowsノードをクラスターに登録する方法を示します。
始める前に
作業するKubernetesサーバーは次のバージョン以降のものである必要があります: 1.17.バージョンを確認するには次のコマンドを実行してください: kubectl version.
WindowsコンテナをホストするWindowsノードを構成するには、Windows Server 2019ライセンス(またはそれ以上)を取得します。 VXLAN/オーバーレイネットワークを使用している場合は、KB4489899もインストールされている必要があります。
コントロールプレーンにアクセスできるLinuxベースのKubernetes kubeadmクラスター(kubeadmを使用したシングルコントロールプレーンクラスターの作成を参照)
目標
- Windowsノードをクラスターに登録する
- LinuxとWindowsのPodとServiceが相互に通信できるようにネットワークを構成する
はじめに: クラスターへのWindowsノードの追加
ネットワーク構成
LinuxベースのKubernetesコントロールプレーンノードを取得したら、ネットワーキングソリューションを選択できます。このガイドでは、簡単にするためにVXLANモードでのFlannelの使用について説明します。
Flannel構成
FlannelのためにKubernetesコントロールプレーンを準備する
クラスター内のKubernetesコントロールプレーンでは、多少の準備が推奨されます。Flannelを使用する場合は、iptablesチェーンへのブリッジIPv4トラフィックを有効にすることをお勧めします。すべてのLinuxノードで次のコマンドを実行する必要があります:
sudo sysctl net.bridge.bridge-nf-call-iptables=1Linux用のFlannelをダウンロードして構成する
最新のFlannelマニフェストをダウンロード:
wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.ymlVNIを4096、ポートを4789に設定するために、flannelマニフェストの
net-conf.jsonセクションを変更します。次のようになります:net-conf.json: | { "Network": "10.244.0.0/16", "Backend": { "Type": "vxlan", "VNI" : 4096, "Port": 4789 } }備考:
Linux上のFlannelがWindows上のFlannelと相互運用するには、VNIを4096およびポート4789に設定する必要があります。これらのフィールドの説明については、VXLANドキュメントを参照してください。備考:
L2Bridge/Host-gatewayモードを使用するには、代わりにTypeの値を"host-gw"に変更し、VNIとPortを省略します。Flannelマニフェストを適用して検証する
Flannelの構成を適用しましょう:
kubectl apply -f kube-flannel.yml数分後、Flannel Podネットワークがデプロイされていれば、すべてのPodが実行されていることがわかります。
kubectl get pods -n kube-system出力結果には、実行中のLinux flannel DaemonSetが含まれているはずです:
NAMESPACE NAME READY STATUS RESTARTS AGE ... kube-system kube-flannel-ds-54954 1/1 Running 0 1mWindows Flannelとkube-proxy DaemonSetを追加する
これで、Windows互換バージョンのFlannelおよびkube-proxyを追加できます。 互換性のあるバージョンのkube-proxyを確実に入手するには、イメージのタグを置換する必要があります。 次の例は、Kubernetes 1.37.0の使用方法を示していますが、 独自のデプロイに合わせてバージョンを調整する必要があります。
curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/kube-proxy.yml | sed 's/VERSION/v1.37.0/g' | kubectl apply -f - kubectl apply -f https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-overlay.yml備考:
ホストゲートウェイを使用している場合は、代わりに https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-host-gw.yml を使用してください。備考:
Windowsノードでイーサネット(「Ethernet0 2」など)ではなく別のインターフェースを使用している場合は、次の行を変更する必要があります:
wins cli process run --path /k/flannel/setup.exe --args "--mode=overlay --interface=Ethernet"flannel-host-gw.ymlまたはflannel-overlay.ymlファイルで、それに応じてインターフェースを指定します。# 例 curl -L https://github.com/kubernetes-sigs/sig-windows-tools/releases/latest/download/flannel-overlay.yml | sed 's/Ethernet/Ethernet0 2/g' | kubectl apply -f -
Windowsワーカーノードの参加
備考:
Containers機能をインストールし、Dockerをインストールする必要があります。
行うための指示としては、Dockerエンジンのインストール - Windowsサーバー上のエンタープライズを利用できます。備考:
Windowsセクションのすべてのコードスニペットは、 Windowsワーカーノードの(管理者)権限を持つPowerShell環境で実行されます。wins、kubelet、kubeadmをインストールします。
curl.exe -LO https://raw.githubusercontent.com/kubernetes-sigs/sig-windows-tools/master/kubeadm/scripts/PrepareNode.ps1 .\PrepareNode.ps1 -KubernetesVersion v1.37.0kubeadmを実行してノードに参加しますコントロールプレーンホストで
kubeadm initを実行したときに提供されたコマンドを使用します。 このコマンドがなくなった場合、またはトークンの有効期限が切れている場合は、kubeadm token create --print-join-command(コントロールプレーンホスト上で)を実行して新しいトークンを生成します。
インストールの確認
次のコマンドを実行して、クラスター内のWindowsノードを表示できるようになります:
kubectl get nodes -o wide
新しいノードがNotReady状態の場合は、flannelイメージがまだダウンロード中の可能性があります。
kube-system名前空間のflannel Podを確認することで、以前と同様に進行状況を確認できます:
kubectl -n kube-system get pods -l app=flannel
flannel Podが実行されると、ノードはReady状態になり、ワークロードを処理できるようになります。
次の項目
1.5 - Linuxノードのアップグレード
このページでは、kubeadmで構築したLinuxワーカーノードのアップグレード方法を示します。
始める前に
全てのノードへのシェルアクセスが可能であり、kubectlコマンドラインツールがクラスターと通信できるように設定されている必要があります。 このチュートリアルでは、コントロールプレーンのホストではないノードが少なくとも2つ存在するクラスターで実行することを推奨します。
バージョンを確認するには次のコマンドを実行してください: kubectl version.
- 残りのkubeadmクラスターのアップグレード手順をよく理解しておいてください。 Linuxワーカーノードをアップグレードする前に、コントロールプレーンノードのアップグレードをする必要があります。
パッケージリポジトリの変更
コミュニティ所有のパッケージリポジトリ(pkgs.k8s.io)を使用している場合、必要なKubernetesのマイナーリリースのパッケージリポジトリを有効化する必要があります。
これは、Kubernetesパッケージリポジトリの変更ドキュメントにて説明されています。
apt.kubernetes.ioおよびyum.kubernetes.io)は2023年9月13日以降、非推奨となり凍結されています。
pkgs.k8s.ioにてホストされている新しいリポジトリの使用が強く推奨されており、2023年9月13日以降にリリースされたKubernetesのバージョンをインストールするには必須となっています。
非推奨の古いリポジトリとその内容は、将来事前予告なく削除される可能性があります。
新しいパッケージリポジトリでは、v1.24.0以降のKubernetesバージョンのダウンロードを提供しています。ワーカーノードのアップグレード
kubeadmのアップグレード
kubeadmをアップグレードします。
#「1.37.x-*」の「x」は最新のパッチバージョンに置き換えてください。
sudo apt-mark unhold kubeadm && \
sudo apt-get update && sudo apt-get install -y kubeadm='1.37.x-*' && \
sudo apt-mark hold kubeadm
DNFを搭載したシステムの場合:
#「1.37.x-*」の「x」は最新のパッチバージョンに置き換えてください。
sudo yum install -y kubeadm-'1.37.x-*' --disableexcludes=kubernetes
DNF5を搭載したシステムの場合:
#「1.37.x-*」の「x」は最新のパッチバージョンに置き換えてください。
sudo yum install -y kubeadm-'1.37.x-*' --setopt=disable_excludes=kubernetes
"kubeadm upgrade"の実行
ワーカーノードは、以下のコマンドによってローカルのkubeletの設定がアップグレードされます。
sudo kubeadm upgrade node
ノードのドレイン
ノードをスケジュール不可としてマークし、ワークロードを退去させることで、ノードのメンテナンスの準備をします。
# このコマンドはコントロールプレーンノードで実行してください。
# <node-to-drain>は、ドレインするノード名に置き換えてください。
kubectl drain <node-to-drain> --ignore-daemonsets
kubeletとkubectlのアップグレード
kubeletとkubectlをアップグレードします。
#「1.37.x-*」の「x」は最新のパッチバージョンに置き換えてください。 sudo apt-mark unhold kubelet kubectl && \ sudo apt-get update && sudo apt-get install -y kubelet='1.37.x-*' kubectl='1.37.x-*' && \ sudo apt-mark hold kubelet kubectlDNFを搭載したシステムの場合:
#「1.37.x-*」の「x」は最新のパッチバージョンに置き換えてください。 sudo yum install -y kubelet-'1.37.x-*' kubectl-'1.37.x-*' --disableexcludes=kubernetesDNF5を搭載したシステムの場合:
#「1.37.x-*」の「x」は最新のパッチバージョンに置き換えてください。 sudo yum install -y kubelet-'1.37.x-*' kubectl-'1.37.x-*' --setopt=disable_excludes=kuberneteskubeletを再起動します。
sudo systemctl daemon-reload sudo systemctl restart kubelet
ノードの隔離解除
ノードをスケジュール可能としてマークすることで、ノードをオンラインに戻します。
# このコマンドはコントロールプレーンノードで実行してください。
# <node-to-uncordon>は対象のノード名に置き換えてください。
kubectl uncordon <node-to-uncordon>
次の項目
- Windowsノードのアップグレードを参照してください。
1.6 - Windowsノードのアップグレード
このページでは、kubeadmで作られたWindowsノードをアップグレードする方法について説明します。
始める前に
Kubernetesクラスターが必要、かつそのクラスターと通信するためにkubectlコマンドラインツールが設定されている必要があります。 このチュートリアルは、コントロールプレーンのホストとして動作していない少なくとも2つのノードを持つクラスターで実行することをおすすめします。 まだクラスターがない場合、minikubeを使って作成するか、 以下のいずれかのKubernetesプレイグラウンドも使用できます:
作業するKubernetesサーバーは次のバージョン以降のものである必要があります: 1.17.バージョンを確認するには次のコマンドを実行してください: kubectl version.
- 残りのkubeadmクラスターをアップグレードするプロセスを理解します。 Windowsノードをアップグレードする前にコントロールプレーンノードをアップグレードしたいと思うかもしれません。
ワーカーノードをアップグレード
kubeadmをアップグレード
Windowsノードから、kubeadmをアップグレードします。:
# 1.37.0を目的のバージョンに置き換えます curl.exe -Lo C:\k\kubeadm.exe https://dl.k8s.io/v1.37.0/bin/windows/amd64/kubeadm.exe
ノードをドレインする
Kubernetes APIにアクセスできるマシンから、 ノードをスケジュール不可としてマークして、ワークロードを削除することでノードのメンテナンスを準備します:
# <node-to-drain>をドレインするノードの名前に置き換えます kubectl drain <node-to-drain> --ignore-daemonsetsこのような出力結果が表示されるはずです:
node/ip-172-31-85-18 cordoned node/ip-172-31-85-18 drained
kubeletの構成をアップグレード
Windowsノードから、次のコマンドを呼び出して新しいkubelet構成を同期します:
kubeadm upgrade node
kubeletをアップグレード
Windowsノードから、kubeletをアップグレードして再起動します:
stop-service kubelet curl