|
| 1 | +--- |
| 2 | +title: クラスターのアップグレード |
| 3 | +content_type: task |
| 4 | +weight: 350 |
| 5 | +--- |
| 6 | + |
| 7 | +<!-- 概要 --> |
| 8 | +このページでは、Kubernetesクラスターをアップグレードする際に従うべき手順の概要を提供します。 |
| 9 | + |
| 10 | +クラスターのアップグレード方法は、初期のデプロイ方法やその後の変更によって異なります。 |
| 11 | + |
| 12 | +大まかな手順は以下の通りです: |
| 13 | + |
| 14 | +- {{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}のアップグレード |
| 15 | +- クラスター内にあるノードのアップグレード |
| 16 | +- {{< glossary_tooltip text="kubectl" term_id="kubectl" >}}など、クライアントのアップグレード |
| 17 | +- 新しいKubernetesバージョンに伴うAPI変更に基づいたマニフェストやその他のリソースの調整 |
| 18 | + |
| 19 | +## {{% heading "prerequisites" %}} |
| 20 | + |
| 21 | +既存のクラスターが必要です。このページではKubernetes {{< skew currentVersionAddMinor -1 >}}からKubernetes {{< skew currentVersion >}}へのアップグレードについて説明しています。現在のクラスターがKubernetes {{< skew currentVersionAddMinor -1 >}}を実行していない場合は、アップグレードしようとしているKubernetesバージョンのドキュメントを確認してください。 |
| 22 | + |
| 23 | +## アップグレード方法 |
| 24 | + |
| 25 | +### kubeadm {#upgrade-kubeadm} |
| 26 | + |
| 27 | +クラスターが`kubeadm`ツールを使用してデプロイされた場合の詳細なアップグレード方法は、[kubeadmクラスターのアップグレード](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/)を参照してください。 |
| 28 | + |
| 29 | +クラスターをアップグレードしたら、忘れずに[最新バージョンの`kubectl`をインストール](/docs/tasks/tools/)してください。 |
| 30 | + |
| 31 | +### 手動デプロイ |
| 32 | + |
| 33 | +{{< caution >}} |
| 34 | +これらの手順は、ネットワークおよびストレージプラグインなどのサードパーティ製拡張機能には対応していません。 |
| 35 | +{{< /caution >}} |
| 36 | + |
| 37 | +次の順序でコントロールプレーンを手動で更新する必要があります: |
| 38 | + |
| 39 | +- etcd(すべてのインスタンス) |
| 40 | +- kube-apiserver(すべてのコントロールプレーンホスト) |
| 41 | +- kube-controller-manager |
| 42 | +- kube-scheduler |
| 43 | +- クラウドコントローラーマネージャー(使用している場合) |
| 44 | + |
| 45 | +この時点で、[最新バージョンの`kubectl`をインストール](/docs/tasks/tools/)してください。 |
| 46 | + |
| 47 | +クラスター内の各ノードに対して、そのノードを[ドレイン](/docs/tasks/administer-cluster/safely-drain-node/)し、{{< skew currentVersion >}} kubeletを使用する新しいノードと置き換えるか、そのノードのkubeletをアップグレードして再稼働させます。 |
| 48 | + |
| 49 | +{{< caution >}} |
| 50 | +kubeletをアップグレードする前にノードをドレインすることで、Podが再収容され、コンテナが再作成されるため、一部のセキュリティ問題や重要なバグの解決が必要な場合があります。 |
| 51 | +{{</ caution >}} |
| 52 | + |
| 53 | +### その他のデプロイ {#upgrade-other} |
| 54 | + |
| 55 | +クラスターデプロイメントツールのドキュメントを参照して、メンテナンスの推奨手順を確認してください。 |
| 56 | + |
| 57 | +## アップグレード後のタスク |
| 58 | + |
| 59 | +### クラスターのストレージAPIバージョンを切り替える |
| 60 | + |
| 61 | +クラスターの内部表現でアクティブなKubernetesリソースのためにetcdにシリアル化されるオブジェクトは、特定のAPIバージョンを使用して書き込まれます。 |
| 62 | + |
| 63 | +サポートされるAPIが変更されると、これらのオブジェクトは新しいAPIで再書き込みする必要があります。これを行わないと、最終的にはKubernetes APIサーバーによってデコードまたは使用できなくなるリソースが発生する可能性があります。 |
| 64 | + |
| 65 | +影響を受ける各オブジェクトについて、最新のサポートされるAPIを使用して取得し、最新のサポートされるAPIを使用して再書き込みします。 |
| 66 | + |
| 67 | +### マニフェストの更新 |
| 68 | + |
| 69 | +新しいKubernetesバージョンへのアップグレードにより、新しいAPIが提供されることがあります。 |
| 70 | + |
| 71 | +異なるAPIバージョン間でマニフェストを変換するために`kubectl convert`コマンドを使用できます。例えば: |
| 72 | + |
| 73 | +```shell |
| 74 | +kubectl convert -f pod.yaml --output-version v1 |
| 75 | +``` |
| 76 | + |
| 77 | +`kubectl`ツールは`pod.yaml`の内容を、`kind`がPod(変更なし)で、`apiVersion`が改訂されたマニフェストに置き換えます。 |
| 78 | + |
| 79 | +### デバイスプラグイン |
| 80 | + |
| 81 | +クラスターがデバイスプラグインを実行しており、ノードを新しいデバイスプラグインAPIバージョンを含むKubernetesリリースにアップグレードする必要がある場合、デバイスプラグインをアップグレードして両方のバージョンをサポートする必要があります。これにより、アップグレード中にデバイスの割り当てが正常に完了し続けることが保証されます。 |
| 82 | + |
| 83 | +詳細については、[API互換性](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#api-compatibility)および[kubeletのデバイスマネージャーAPIバージョン](/docs/reference/node/device-plugin-api-versions/)を参照してください。 |
0 commit comments