次の方法で共有

Azure Kubernetes Service (AKS) の Linux ノードにセキュリティとカーネルの更新を適用します

  • [アーティクル]

クラスターを保護するために、AKS のノードにセキュリティ更新プログラムが自動的に適用されます。 これらの更新プログラムには、OS のセキュリティ修正プログラムやカーネルの更新プログラムが含まれています。 これらの更新プログラムの中には、プロセスを完了するためにノードの再起動が必要なものがあります。 AKS は、更新プロセスを完了するためにこれらの Linux ノードを自動的に再起動しません。

Windows サーバー ノードを最新に保つためのプロセスは少し異なります。 Windows Server ノードは、毎日の更新を受信しません。 代わりに、最新の Windows Server の基本イメージと修正プログラムを含む新しいノードをデプロイする AKS アップグレードを実行します。 Windows Server ノードを使用する AKS クラスターについては、「AKS でのノード プールのアップグレード」をご覧ください。

この記事では、オープンソースの kured (KUbernetes REboot Daemon) を使用して、再起動が必要な Linux ノードを監視し、ポッドの実行やノード再起動プロセスのスケジュール変更を自動的に処理する方法について説明します。

Note

Kured は、Cloud Native Computing Foundation 内のオープンソース プロジェクトです。 Kured GitHub に問題を報告してください。 追加のサポートは、CNCF Slack 上の #kured チャネルで確認できます。

重要

オープンソース ソフトウェアは、AKS のドキュメントとサンプル全体で説明されています。 デプロイするソフトウェアは、AKS サービス レベル アグリーメント、限定保証、Azure サポートから除外されます。 AKS と共にオープンソース テクノロジを使用する場合は、それぞれのコミュニティとプロジェクト保守担当者から受けられるサポート オプションを調べ、計画を策定してください。

たとえば、Ray の GitHub リポジトリでは、応答時間、目的、サポート レベルが異なる複数のプラットフォームについて説明しています。

Microsoft は、AKS 上に展開するオープンソース パッケージを構築する責任を負います。 その責任には、ビルド、スキャン、署名、検証、修正プログラム プロセスの完全な所有権と、コンテナー イメージ内のバイナリの制御権が伴います。 詳細については、「AKS の脆弱性の管理」と「AKS のサポート範囲」を参照してください。

開始する前に

Azure CLI バージョン 2.0.59 以降がインストールされて構成されている必要があります。 バージョンを確認するには、az --version を実行します。 インストールまたはアップグレードする必要がある場合は、Azure CLI のインストールに関するページを参照してください。

AKS ノードの更新エクスペリエンスを理解する

AKS クラスターでは、お客様の Kubernetes ノードが Azure 仮想マシン (VM) として実行されます。 これらは Ubuntu や Azure Linux イメージが使用される Linux ベースの VM です。その OS は、更新プログラムの有無を毎日自動的にチェックするように構成されています。 セキュリティまたはカーネルの更新プログラムが公開された場合、それらが自動的にダウンロードされてインストールされます。

kured を使用した AKS ノードの更新と再起動のプロセス

カーネルの更新プログラムなど、一部のセキュリティ更新プログラムでは、プロセスの最後にノードを再起動する必要があります。 再起動が必要な Linux ノードでは、 /var/run/reboot-required という名前のファイルが作成されます。 この再起動プロセスは自動的には実行されません。

お客様独自のワークフローとプロセスを使用してノードの再起動を管理するか、kured を使用してプロセスを調整することができます。 kured を使用すると、クラスター内の各 Linux ノードでポッドを実行する DaemonSet がデプロイされます。 DaemonSet 内のこれらのポッドによって /var/run/reboot-required ファイルの存在が監視され、ノードの再起動プロセスが開始されます。

ノード イメージのアップグレード

無人アップグレードでは、Linux ノード OS にアップデートが適用されますが、クラスターのノードを作成するためのイメージは変更されません。 新しい Linux ノードがクラスターに追加された場合は、元のイメージを使用してノードが作成されます。 この新しいノードは、毎日の自動チェックで利用可能なすべてのセキュリティおよびカーネル アップデートを受け取りますが、すべてのチェックと再起動が完了するまではパッチは適用されません。

また、ノード イメージのアップグレードを使用して、クラスターで使用されているノード イメージをチェックして更新することもできます。 ノード イメージのアップグレードに関する詳細については、「Azure Kubernetes Service (AKS) ノード イメージのアップグレード」を参照してください。

ノードのアップグレード

AKS には、クラスターを "アップグレード" するための別のプロセスがあります。 通常、アップグレードとは、ノードのセキュリティ更新プログラムを適用するだけでなく、より新しいバージョンの Kubernetes に移行することを言います。 AKS のアップグレードでは、次のアクションが実行されます。

  • 最新のセキュリティ更新プログラムと Kubernetes バージョンを適用した新しいノードがデプロイされます。
  • 以前のノードが切断およびドレインされます。
  • ポッドが新しいノードに対してスケジュールされます。
  • 以前のノードが削除されます。

アップグレード イベント中、同じ Kubernetes バージョンを維持することはできません。 より新しいバージョンの Kubernetes を指定する必要があります。 最新バージョンの Kubernetes にアップグレードするために、AKS クラスターをアップグレードできます。

AKS クラスターに kured をデプロイする

kured DaemonSet をデプロイするには、次の公式 Kured Helm グラフをインストールします。 これによって、ロールおよびクラスター ロール、バインディング、サービス アカウントが作成された後、 kured を使用して、DaemonSet がデプロイされます。

# Add the Kured Helm repository
helm repo add kubereboot https://kubereboot.github.io/charts/

# Update your local Helm chart repository cache
helm repo update

# Create a dedicated namespace where you would like to deploy kured into
kubectl create namespace kured

# Install kured in that namespace with Helm 3 (only on Linux nodes, kured is not working on Windows nodes)
helm install my-release kubereboot/kured --namespace kured --set controller.nodeSelector."kubernetes\.io/os"=linux

kured には、Prometheus や Slack との統合など、追加のパラメーターを構成することもできます。 構成パラメーターの詳細については、kured Helm グラフをご参照ください。

クラスター ノードを更新する

既定では、AKS の Linux ノードによって更新プログラムの有無が毎晩チェックされます。 待ちたくない場合は、手動で更新を行うことで、kured が正常に実行されていることを確認できます。 まず、お客様の AKS ノードのいずれかに SSH で接続する手順に従ってください。 Linux ノードに SSH で接続したら、次のように更新プログラムの有無をチェックして適用します。

sudo apt-get update && sudo apt-get upgrade -y

ノードの再起動を必要とする更新プログラムが適用された場合、 /var/run/reboot-required にファイルが書き込まれます。 既定では、再起動を必要とするノードの有無が Kured によって 60 分おきにチェックされます。

再起動プロセスを監視、確認する

デーモンセット内のいずれかのレプリカが、ノードの再起動が必要であることを検出すると、Kubernetes API を介してそのノードにロックが設定されます。 このロックによって、そのノードに追加のポッドをスケジュールすることが禁止されます。 また、このロックによって、一度に再起動するノードを 1 つのみとすることが示されます。 ノードが切断された状態で、実行中のポッドがノードからドレインされて、ノードが再起動されます。

ノードの状態は、kubectl get nodes コマンドを使用して監視することができます。 次の出力例は、再起動のプロセス待ちであるために SchedulingDisabled 状態となっているノードを示しています。

NAME                       STATUS                     ROLES     AGE       VERSION
aks-nodepool1-28993262-0   Ready,SchedulingDisabled   agent     1h        v1.11.7

更新プロセスが完了したら、kubectl get nodes コマンドに --output wide パラメーターを指定してノードの状態を確認できます。 この出力によって、基になるノードの KERNEL-VERSION の違いを確認することができます。次の出力例をご覧ください。 前の手順で aks-nodepool1-28993262-0 が更新され、カーネル バージョンが 4.15.0-1039-azure になっていることがわかります。 更新されていないノード aks-nodepool1-28993262-1 は、カーネル バージョンが 4.15.0-1037-azure であることを示しています。

NAME                       STATUS    ROLES     AGE       VERSION   INTERNAL-IP   EXTERNAL-IP   OS-IMAGE             KERNEL-VERSION      CONTAINER-RUNTIME
aks-nodepool1-28993262-0   Ready     agent     1h        v1.11.7   10.240.0.4    <none>        Ubuntu 16.04.6 LTS   4.15.0-1039-azure   docker://3.0.4
aks-nodepool1-28993262-1   Ready     agent     1h        v1.11.7   10.240.0.5    <none>        Ubuntu 16.04.6 LTS   4.15.0-1037-azure   docker://3.0.4

次のステップ

この記事では、kured を使用し、セキュリティ更新プロセスの一環として Linux ノードを自動的に再起動する方法について説明しました。 最新バージョンの Kubernetes にアップグレードするために、AKS クラスターをアップグレードできます。

Windows Server ノードを使用する AKS クラスターについては、「AKS でのノード プールのアップグレード」をご覧ください。

アップグレードのベスト プラクティスとその他の考慮事項の詳細については、AKS のパッチとアップグレード ガイダンスのページを参照してください。