このトピックでは、CoreDNS のアップグレード前のチェックと最適化、および自動アップグレードを実行する手順について説明します。
前提条件
kubectl ツールを使用してクラスターに接続します。詳細については、「kubectl を使用してクラスターに接続する」をご参照ください。
CoreDNS のアップグレードプロセス
CoreDNS のアップグレード中、ACK は RollingUpgrade モードを使用して CoreDNS の Deployment を更新します。このモードでは、新しい CoreDNS Pod が実行された後にのみ、古い Pod が削除されます。CoreDNS Pod の数はアップグレード後も変わりません。ただし、アップグレード中に古い Pod がまだ DNS 解像度リクエストを処理している場合、リクエストが失敗する可能性があります。クラスター内の DNS サービスの可用性を確保するために、NodeLocal DNSCache コンポーネントを使用できます。詳細については、「NodeLocal DNSCache コンポーネントを使用する」をご参照ください。
以前に Toleration、メモリと CPU のリソースリクエスト、およびリミットなどのフィールドを変更して YAML テンプレートをカスタマイズした場合、これらのカスタマイズは上書きされます。この場合、CoreDNS を手動でアップグレードするか、自動アップグレードの完了後に YAML テンプレートにカスタマイズを再適用する必要があります。手動アップグレードの実行方法の詳細については、「管理外 CoreDNS を手動でアップグレードする」をご参照ください。
kube-proxy のロードバランシングモードとして IPVS を使用する場合、CoreDNS のアップグレード完了後 5 分以内にクラスター全体の DNS 解像度のタイムアウトまたは失敗が発生する可能性があります。この IPVS のバグの影響を軽減するには、次のいずれかの方法を使用できます。
kube-proxy で IPVS UDP セッション維持のタイムアウトを変更します。詳細については、「kube-proxy で IPVS UDP セッション維持のタイムアウトを変更するにはどうすればよいですか?」をご参照ください。
NodeLocal DNSCache を使用します。詳細については、「NodeLocal DNSCache を使用する」をご参照ください。
クラスターノードが Alibaba Cloud Linux 2 を使用している場合、ノードカーネルを 4.19.91-25.1.al7.x86_64 以降のバージョンにアップグレードします。Alibaba Cloud Linux 2 のリリースノートの詳細については、「Alibaba Cloud Linux 2 イメージリリースノート」をご参照ください。
クラスターノードが他のオペレーティングシステムを使用している場合は、この問題を回避するために IPVS クラスターの UDP タイムアウトを設定します。詳細については、「IPVS クラスターの UDP タイムアウトを設定する」をご参照ください。
前述の操作を実行したくない場合は、CoreDNS をアップグレードする前に、すべてのアプリケーションコンテナーを NodeLocal DNSCache に接続できます。詳細については、「NodeLocal DNSCache コンポーネントを使用する」をご参照ください。
アップグレードプロセスには約 2 分かかります。実際に必要な時間は、クラスター内の CoreDNS レプリカの数によって異なる場合があります。アップグレードでは、古いレプリカがすぐに停止されない正常な終了ポリシーが使用されます。これにより、アプリケーションの DNS 解像度が影響を受けないことが保証されます。アップグレードが失敗した場合、システムは 10 分以内に自動的にロールバックを実行します。
ready プラグインを有効にする
CoreDNS を 1.5.0 より後のバージョンに手動でアップグレードした場合、CoreDNS 設定ファイルで ready プラグインが有効になっているかどうかを確認します。ready プラグインが有効になっていない場合は、自動アップグレードを実行する前に ready プラグインを有効にする必要があります。そうしないと、CoreDNS の起動に失敗します。
ACK コンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
クラスター ページで、変更するクラスターの名前をクリックします。左側のナビゲーションウィンドウで、 を選択します。
[ConfigMap] ページで、ページ上部の [名前空間] を kube-system に設定します。次に、coredns を見つけ、[アクション] 列の [YAML の編集] をクリックします。
[YAML の表示] パネルで、
readyフィールドを確認します。フィールドが存在しない場合は、readyフィールドを追加して [OK] をクリックします。apiVersion: v1 data: Corefile: | .:53 { errors health { lameduck 15s } ready # この行が存在しない場合は追加します。インデントが kubernetes と一致していることを確認してください。 kubernetes cluster.local in-addr.arpa ip6.arpa { pods verified fallthrough in-addr.arpa ip6.arpa } prometheus :9153 forward . /etc/resolv.conf { max_concurrent 1000 } cache 30 loop log reload loadbalance }次のコマンドを実行して、CoreDNS 設定が CoreDNS Pod の標準出力にロードされているかどうかを確認します。新しい設定は、約 30 秒でホットリロードされます。
kubectl logs coredns-78d4b8bd88-n6wjm -n kube-system期待される出力には
plugin/reload情報が含まれており、これは CoreDNS 設定がロードされたことを示します。
アップグレードの開始
ACK コンソールの [コンポーネント管理] ページから CoreDNS のバージョンをアップグレードできます。
ACK コンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
クラスター ページで、管理するクラスターを見つけてその名前をクリックします。左側のナビゲーションウィンドウで、[アドオン] をクリックします。
[コンポーネント管理] ページで、CoreDNS を検索し、[アップグレード] をクリックします。
IPVS クラスターの UDP タイムアウトを設定する
クラスターが kube-proxy IPVS モードを使用している場合、IPVS セッション維持ポリシーにより、アップグレード後 5 分間、クラスター全体で断続的な DNS解決の失敗が発生する可能性があります。解決の失敗回数を減らすには、IPVS UDP セッション維持のタイムアウトを 10 秒に短縮します。クラスターに UDP ベースのサービスがある場合は、続行する前にこの操作の潜在的な影響を評価してください。
クラスターが IPVS クラスターでない場合は、このセクションを無視できます。kube-proxy プロキシモードの確認方法の詳細については、「クラスター情報の表示」をご参照ください。
Kubernetes 1.18 以降のクラスターの場合
コンソールを使用する
ACK コンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
クラスター ページで、変更するクラスターの名前をクリックします。左側のナビゲーションウィンドウで、 を選択します。
[ConfigMap] ページで、[kube-system] 名前空間を選択します。kube-proxy-worker ConfigMap を見つけ、[アクション] 列の [YAML の編集] をクリックします。
[YAML の表示] パネルで、ipvs フィールドの下に
udpTimeout: 10sを追加し、[OK] をクリックします。apiVersion: v1 data: config.conf: | apiVersion: kubeproxy.config.k8s.io/v1alpha1 kind: KubeProxyConfiguration # 他の無関係なフィールドは省略されています。 mode: ipvs # ipvs キーが存在しない場合は追加します。 ipvs: udpTimeout: 10skube-proxy-worker という名前のすべての Pod を再作成します。
[クラスター情報] ページの左側のナビゲーションウィンドウで、 を選択します。
DaemonSet リストで、[kube-proxy-worker] を見つけてクリックします。
[kube-proxy-worker] ページで、[Pod] タブをクリックします。Pod の行で、 を選択し、[OK] をクリックします。
この手順を繰り返して、すべての Pod を削除します。Pod が削除されると、システムは自動的にそれらを再作成します。
UDP タイムアウトが設定されていることを確認します。
次のコマンドを実行して [ipvsadm] をインストールします。
[ipvsadm] は IPVS モジュールの管理ツールです。詳細については、「ipvsadm」をご参照ください。
sudo yum install -y ipvsadmクラスター内の任意の ECS ノードで次のコマンドを実行し、出力の 3 番目の数値を確認します。
sudo ipvsadm -L --timeout出力の 3 番目の数値が 10 の場合、IPVS クラスターの UDP タイムアウトは正常に変更されています。
変更が成功したら、次のステップに進む前に少なくとも 5 分間待ってください。
コマンドラインを使用する
次のコマンドを実行して、kube-proxy-worker 設定ファイルを編集します。
kubectl -n kube-system edit configmap kube-proxy-workerkube-proxy 設定ファイルで、ipvs フィールドの下に
udpTimeout: 10sを追加します。次に、ファイルを保存して終了します。apiVersion: v1 data: config.conf: | apiVersion: kubeproxy.config.k8s.io/v1alpha1 kind: KubeProxyConfiguration # 他の無関係なフィールドは省略されています。 mode: ipvs # ipvs キーが存在しない場合は追加します。 ipvs: udpTimeout: 10s次のコマンドを実行して、kube-proxy-worker という名前のすべての Pod を再作成します。
次のコマンドを実行して、既存の Pod に関する情報を表示します。
kubectl -n kube-system get pod -o wide | grep kube-proxy-worker次のコマンドを実行して、前のステップで見つけた Pod を削除します。システムは、kube-proxy-worker という名前の Pod を自動的に再作成します。
kubectl -n kube-system delete pod <kube-proxy-worker-****><kube-proxy-worker-****> を前のステップで見つけた Pod の名前に置き換えます。
UDP タイムアウトが設定されていることを確認します。
次のコマンドを実行して [ipvsadm] をインストールします。
[ipvsadm] は IPVS モジュールの管理ツールです。詳細については、「ipvsadm」をご参照ください。
sudo yum install -y ipvsadmクラスター内の任意の ECS ノードで次のコマンドを実行し、出力の 3 番目の数値を確認します。
sudo ipvsadm -L --timeout出力の 3 番目の数値が 10 の場合、IPVS クラスターの UDP タイムアウトは正常に変更されています。
変更が成功したら、次のステップに進む前に少なくとも 5 分間待ってください。
Kubernetes 1.16 以前のクラスターの場合
これらのバージョンを実行するクラスターの kube-proxy コンポーネントは、udpTimeout パラメーターをサポートしていません。Operation Orchestration Service (OOS) を使用して、すべてのクラスターノードで ipvsadm コマンドをバッチで実行し、UDP タイムアウト設定を調整できます。コマンドは次のとおりです。
sudo yum install -y ipvsadm
sudo ipvsadm -L --timeout > /tmp/ipvsadm_timeout_old
sudo ipvsadm --set 900 120 10
sudo ipvsadm -L --timeout > /tmp/ipvsadm_timeout_new
diff /tmp/ipvsadm_timeout_old /tmp/ipvsadm_timeout_newOOS でのバッチ操作の詳細については、「バッチ操作インスタンス」をご参照ください。
次のステップ
アップグレードが完了したら、CoreDNS を最適化および設定できます。詳細については、「CoreDNS 設定の最適化」をご参照ください。