このトピックでは、TerwayおよびFlannelネットワークプラグインの使用に関するよくある質問 (FAQ) に対する回答を提供します。 たとえば、ネットワークプラグインの選択方法、クラスタがサードパーティのネットワークプラグインをサポートするかどうか、クラスタネットワークの計画方法などの質問に対する回答が提供されます。
目次
Terwayに関連する問題
クラスターのvSwitchを作成した後、Terwayでインストールされたクラスターがインターネットにアクセスできない場合はどうすればよいですか?
Terwayネットワークプラグインが排他的ENIモードで使用されているときに発生するネットワークエラーを解決するにはどうすればよいですか?
Terwayと共にインストールされたACKクラスターのアイドル状態のvSwitch IPアドレスが不十分な場合はどうすればよいですか?
新しく作成されたポッドのIPアドレスがTerwayモードのvSwitch CIDRブロックに含まれない場合はどうすればよいですか?
TerwayモードでvSwitchを追加した後、新しく作成されたポッドのIPアドレスがvSwitch CIDRブロックに含まれない場合はどうすればよいですか?
Terway更新の失敗のトラブルシューティング
フランネルに関連する問題
Flannelを手動で更新した後、FlannelがKubernetes 1.16のクラスターと互換性がなくなった場合はどうすればよいですか。
ポッドの起動に失敗し、「範囲内で使用可能なIPアドレスはありません」というエラーメッセージが表示された場合はどうすればよいですか?
kube-proxyに関連する問題
IPv6に関連する問題
IPv4/IPv6デュアルスタックに関連する一般的な問題を修正する方法?
その他の問題
既存のACKクラスターのネットワークプラグインを切り替えることはできますか?
ACKクラスターを作成する場合にのみ、ネットワークプラグイン (TerwayまたはFlannel) を選択できます。 クラスターの作成後にプラグインを変更することはできません。 ネットワークプラグインを切り替える場合は、新しいクラスターを作成する必要があります。 詳細については、「ACK管理クラスターの作成」をご参照ください。
クラスターのvSwitchを作成した後、Terwayでインストールされたクラスターがインターネットにアクセスできない場合はどうすればよいですか?
問題の説明
Terwayネットワークで、ポッドのIPアドレスを増やすために新しいvSwitchを作成すると、Container Service for Kubernetes (ACK) クラスターはインターネットにアクセスできません。
原因
ポッドにIPアドレスを割り当てる新しいvSwitchは、インターネットにアクセスできません。
解決策
NATゲートウェイを作成し、SNATルールを設定して、新しいvSwitchがインターネットにアクセスできるようにします。 詳細については、「既存のACKクラスターによるインターネットへのアクセスの有効化」をご参照ください。
Flannelを手動で更新した後、FlannelがKubernetes 1.16のクラスターと互換性がなくなった場合はどうすればよいですか。
問題の説明
クラスターのKubernetesバージョンが1.16以降に更新されると、クラスター内のノードはNotReady状態に変わります。
原因
Flannelプラグインは手動で更新されますが、Flannelの構成は古くなっています。 その結果、kubeletはフランネルを認識できません。
解決策
次のコマンドを実行して、
cniVersionフィールドをFlannel構成ファイルに追加します。kubectl edit cm kube-flannel-cfg -n kube-systemcniVersionフィールドを構成ファイルに追加します。"name": "cb0", "cniVersion":"0.3.0", "type": "flannel",次のコマンドを実行してFlannelを再起動します。
kubectl delete pod -n kube-system -l app=flannel
ポッドの起動後すぐに通信の準備ができていない場合はどうすればよいですか?
問題の説明
ポッドの起動後、ポッドが通信できるようになるまでしばらく待つ必要があります。
原因
ネットワークポリシーは、有効になるために一定の期間を必要とする。 この問題を解決するには、ネットワークポリシーを無効にします。
解決策
次のコマンドを実行して、TerwayのConfigMapを変更し、ネットワークポリシーを無効にします。
kubectl edit cm -n kube-system eni-configConfigMapに次のフィールドを追加します。
disable_network_policy: "true"オプションです。Terwayバージョンが最新でない場合は、ACKコンソールで最新バージョンに更新します。
ACKコンソールにログインします。 左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理するクラスターの名前をクリックします。 左側のウィンドウで、 を選択します。
アドオンページで、ネットワーキングタブをクリックし、Terwayプラグインを見つけ、アップグレードをクリックします。
NoteメッセージでOKをクリックします。
次のコマンドを実行して、すべてのTerwayポッドを再起動します。
kubectl delete pod -n kube-system -l app=terway-eniip
ポッドを公開するために使用されるサービスにポッドがアクセスできるようにするにはどうすればよいですか。
問題の説明
ポッドは、公開に使用されるサービスにアクセスできません。 ポッドがポッドを公開するサービスにアクセスすると、サービスのパフォーマンスが不安定になるか、スケジューリングエラーが発生する可能性があります。
原因
クラスターは、ループバックリクエストを許可しないFlannelバージョンを使用しています。
0.15.1.4より前のバージョン-e02c8f12-aliyunはループバックリクエストを許可しません。 デフォルトでは、Flannelを0.15.1.4 e02c8f12-aliyun以降に直接更新する場合、ループバック要求は許可されません。
ループバックリクエストを許可するには、現在のFlannelバージョンをアンインストールしてからFlannel 0.15.1.4 e02c8f12-aliyun以降をインストールする必要があります。
解決策
ヘッドレスサービスを使用してアプリケーションを公開し、アクセスします。 詳細については、「ヘッドレスサービス」をご参照ください。
説明この方法を使用することを推奨します。
Terwayを使用するようにクラスターを再作成します。 詳細については、「Terwayでの作業」をご参照ください。
Flannel構成を変更し、Flannelを再インストールしてから、ポッドを再作成します。
説明Flannelの更新時にFlannelの構成が上書きされる可能性があるため、この方法は使用しないことを推奨します。
次のコマンドを実行して、cni-config.jsonを変更します。
kubectl edit cm kube-flannel-cfg -n kube-systemdelegateパラメーターにhairpinMode: trueを追加します。サンプルコード：
cni-conf.json: | { "name": "cb0", "cniVersion":"0.3.1", "type": "flannel", "delegate": { "isDefaultGateway": true, "hairpinMode": true } }次のコマンドを実行してFlannelを再起動します。
kubectl delete pod -n kube-system -l app=flannelポッドを削除して再作成します。
ACKクラスターに対してTerwayとFlannelを選択するにはどうすればよいですか?
次のセクションでは、ACKクラスターに使用できるFlannelおよびTerwayネットワークプラグインについて説明します。
ACKクラスターを作成するときに、ネットワークプラグインの1つを選択できます。
Flannel: Kubernetesコミュニティによって開発されたシンプルで安定したContainer Network Interface (CNI) プラグイン。 Alibaba CloudのVirtual Private Cloud (VPC) が提供する高速ネットワークと一緒にFlannelを使用できます。 これにより、クラスターとコンテナーを高いパフォーマンスで安定したネットワークで実行できます。 ただし、Flannelは基本機能のみを提供し、標準のKubernetesネットワークポリシーをサポートしていません。
Terway: ACKによって開発されたネットワークプラグイン。 TerwayはFlannelのすべての機能を提供し、Alibaba Cloud elastic network Interface (ENI) をコンテナーにアタッチできます。 Terwayを使用して、標準のKubernetesネットワークポリシーに基づいてコンテナーのアクセス制御ポリシーを設定できます。 また、Terway は個々のコンテナで帯域幅調整をサポートしています。 Kubernetesネットワークポリシーを使用しない場合は、Flannelを選択できます。 それ以外の場合は、Terwayを選択することをお勧めします。 Terwayの詳細については、「Terwayでの作業」をご参照ください。
クラスターのネットワークを計画するにはどうすればよいですか。
ACKクラスターを作成するときは、VPC、vSwitch、ポッドCIDRブロック、およびサービスCIDRブロックを指定する必要があります。 ACKクラスターを作成する前に、クラスター内のElastic Compute Service (ECS) インスタンスのCIDRブロック、ポッドCIDRブロック、およびサービスCIDRブロックを計画することを推奨します。 詳細については、「ACKクラスターのネットワークの計画」をご参照ください。
hostPort機能を使用してACKクラスターにポートマッピングを作成できますか?
Flannelのみが、hostPort機能を使用してACKクラスターにポートマッピングを作成できます。
VPC内のポッドは、VPC内のポッドのエンドポイントを使用して、同じVPC内にデプロイされている他のクラウドリソースからアクセスできます。 したがって、ポートマッピングは不要である。
アプリケーションをインターネットに公開するには、NodePortサービスまたはLoadBalancerサービスを使用できます。
クラスターのネットワークタイプとvSwitchを確認するにはどうすればよいですか?
ACKは、FlannelとTerwayの2種類のコンテナネットワークをサポートしています。
クラスターのネットワークタイプを確認するには、次の手順を実行します。
ACK コンソールにログインします。 左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理するクラスターを見つけ、その名前をクリックします。 [操作] 列の [詳細] をクリックして、クラスターの詳細ページに移動することもできます。
[基本情報] タブで、[クラスター情報] セクションの [ネットワークプラグイン] パラメーターの値を確認します。
Network Plug-inパラメーターの値がterway-eniipの場合、Terwayが使用されます。
Network Plug-inパラメーターの値がFlannelの場合、Flannelが使用されます。
ネットワーク内のノードが属するvSwitchを確認するには、次の手順を実行します。
ACK コンソールにログインします。 左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理するクラスターの名前をクリックします。 左側のウィンドウで、 を選択します。
[ノードプール] ページで、管理するノードプールを見つけ、[操作] 列の [詳細] をクリックします。
[概要] タブの [ノード設定] セクションで、[ノードvSwitch] パラメーターの値を確認します。
Terwayネットワークのポッドが属するvSwitchを確認するには、次の手順を実行します。
Terwayネットワーク内のポッドのみがvSwitchを必要とします。 FlannelネットワークのポッドはvSwitchを必要としません。
ACK コンソールにログインします。 左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理するクラスターを見つけ、その名前をクリックします。 [操作] 列の [詳細] をクリックして、クラスターの詳細ページに移動することもできます。
クラスターの詳細ページで、[クラスターリソース] タブをクリックし、[ポッドvSwitch] パラメーターの値を確認します。
ACKクラスターで使用されているクラウドリソースを確認するにはどうすればよいですか。
次の手順を実行して、ワーカーノードに割り当てられているvSwitch、VPC、Resource Access Management (RAM) ロールなど、ACKクラスターで使用されているクラウドリソースを確認します。
ACK コンソールにログインします。 左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理するクラスターを見つけ、その名前をクリックします。 [操作] 列の [詳細] をクリックして、クラスターの詳細ページに移動することもできます。
[クラスターリソース] タブで、クラスターで使用されているクラウドリソースを表示します。
kube-proxy設定を変更するにはどうすればよいですか?
デフォルトでは、負荷分散のために、kube-proxy-workerという名前のDaemonSetがACK管理クラスターにデプロイされます。 kube-proxy-workerという名前のConfigMapを変更して、kube-proxy-worker DaemonSetのパラメーターを変更できます。 ACK専用クラスターを使用する場合、DaemonSetとConfigMapの両方ともkube-proxy-masterという名前が各マスターノードにデプロイされます。
ACKのkube-proxy設定項目は、オープンソースのKubeProxyConfigurationと完全に互換性があります。 設定をカスタマイズするときは、オープンソースのバージョンを参照できます。 詳細は、「kube-proxy設定 (v1alpha 1) 」をご参照ください。 kube-proxy設定は、特定の形式に準拠する必要があります。 コロン (:) またはスペース文字を省略しないでください。 kube-proxy設定を変更するには、次の手順を実行します。
ACK管理クラスターを使用する場合は、次の手順を実行してkube-proxy-worker ConfigMapを変更します。
ACK コンソールにログインします。 左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理するクラスターの名前をクリックします。 左側のウィンドウで、 を選択します。
ConfigMapページの上部で、[名前空間] ドロップダウンリストから [kube-system] を選択します。 kube-proxy-worker ConfigMapを見つけ、[操作] 列の [YAMLの編集] をクリックします。
[YAMLで表示] パネルでパラメーターを変更し、[OK] をクリックします。
設定を有効にするために、すべてのkube-proxy-workerポッドを再作成します。
重要kube-proxyを再起動しても、ワークロードは中断されません。 ただし、kube-proxyが再起動されるまで待つ必要があるため、新しいリリースは延期されます。 オフピーク時にkube-proxyを再起動することを推奨します。
クラスターの詳細ページの左側のウィンドウで、 を選択します。
[DaemonSets] ページで、kube-proxy-workerを見つけ、その名前をクリックします。
kube-proxy-workerの詳細ページの [ポッド] タブでポッドを選択し、[操作] 列の を選択します。 表示されるメッセージで、[OK] をクリックします。
上記の手順を繰り返して、すべてのポッドを削除します。 ポッドを削除すると、システムは自動的にポッドを再作成します。
ACK専用クラスターを使用する場合は、kube-proxy-workerおよびkube-proxy-master Configmapsを変更し、kube-proxy-workerおよびkube-proxy-masterポッドを削除します。 システムは自動的にそれらを再作成します。 詳細については、前述の手順をご参照ください。
Linuxカーネルのconntrackテーブルで追跡される接続の最大数を増やすにはどうすればよいですか?
dmesgコマンドを実行した後にconntrack fullエラーメッセージが返された場合、conntrackテーブルで追跡される接続の数がconntrack_maxパラメーターで指定された制限を超えています。 この場合、conntrackテーブルで追跡される接続の最大数を増やす必要があります。
conntrack -Lコマンドを実行して、conntrackテーブルの接続で使用されるプロトコルの比率を確認します。多数のTCP接続が見つかった場合は、アプリケーションタイプを確認し、永続接続を使用して短命接続を置き換えることを検討する必要があります。
多数のDNS接続が見つかった場合は、NodeLocal DNSCacheを使用してクラスターのDNSパフォーマンスを向上させる必要があります。 詳細については、「NodeLocal DNSCacheの設定」をご参照ください。
conntrackテーブル内の接続の比率が適切な場合、またはアプリケーションを変更しない場合は、kube-proxy設定にmaxPerCoreパラメーターを追加して、追跡される接続の最大数を調整できます。
ACK管理クラスターを使用する場合は、kube-proxy-worker ConfigMapにmaxPerCoreパラメーターを追加し、このパラメーターを65536以上に設定します。 次に、kube-proxy-workerポッドを削除します。 システムは、設定が有効になるようにポッドを自動的に再作成します。 kube-proxy-worker ConfigMapを変更してポッドを削除する方法の詳細については、kube-proxy設定を変更するにはどうすればよいですか? このトピックのセクション。
apiVersion: v1 kind: ConfigMap metadata: name: kube-proxy-worker namespace: kube-system data: config.conf: | apiVersion: kubeproxy.config.k8s.io/v1alpha1 kind: KubeProxyConfiguration featureGates: IPv6DualStack: true clusterCIDR: 172.20.0.0/16 clientConnection: kubeconfig: /var/lib/kube-proxy/kubeconfig.conf conntrack: maxPerCore: 65536 // Set the maxPerCore parameter to a proper value. Default value: 65536. mode: ipvs # Irrelevant fields are omitted.ACK専用クラスターを使用する場合は、kube-proxy-workerおよびkube-proxy-master ConfigMapsにmaxPerCoreパラメーターを追加し、このパラメーターを65536以上に設定します。 次に、kube-proxy-workerポッドとkube-proxy-masterポッドを削除します。 システムは、設定を有効にするためにポッドを自動的に再作成します。 kube-proxy-workerおよびkube-proxy-master ConfigMapsを変更し、それらのポッドを削除する方法の詳細については、kube-proxy設定を変更するにはどうすればよいですか? このトピックのセクション。
kube-proxy構成でIPVS負荷分散アルゴリズムを変更するにはどうすればよいですか?
次の手順を実行して、kube-proxy構成のIPVS負荷分散アルゴリズムを変更し、多数の永続接続が均等に分散されないという問題を解決します。
適切なスケジューリングアルゴリズムを選択します。 スケジューリングアルゴリズムの選択方法の詳細については、「Kubernetesドキュメントのパラメーターの変更」をご参照ください。
デフォルトでは、10月2022日より前に作成されたクラスターノードでは、すべてのIPVSスケジューリングアルゴリズムが有効になっていない場合があります。 すべてのクラスターノードでIPVSカーネルモジュールを手動で有効にする必要があります。 この例では、最小接続アルゴリズムが使用される。 他のスケジューリングアルゴリズムを使用する場合は、lcキーワードを置き換えます。 各ノードにログインし、lsmod | grep ip_vs_lcコマンドを実行し、出力を確認します。
出力にip_vs_lcが含まれている場合、カーネルモジュールが読み込まれます。 このステップはスキップできます。
カーネルモジュールが読み込まれていない場合は、modprobe ip_vs_lcコマンドを実行して、ノードを直ちに有効にします。 次に、echo "ip_vs_lc" >> /etc/modules-load.d/ack-ipvs-modules.confコマンドを実行して、ノードを再起動します。
ipvs schedulerパラメーターを適切なスケジューリングアルゴリズムに設定します。
ACK管理クラスターを使用する場合は、kube-proxy-worker ConfigMapでipvs schedulerパラメーターを適切なスケジューリングアルゴリズムに設定します。 次に、kube-proxy-workerポッドを削除します。 システムは、設定が有効になるようにポッドを自動的に再作成します。 kube-proxy-worker ConfigMapを変更してポッドを削除する方法の詳細については、kube-proxy設定を変更するにはどうすればよいですか? このトピックのセクション。
apiVersion: v1 kind: ConfigMap metadata: name: kube-proxy-worker namespace: kube-system data: config.conf: | apiVersion: kubeproxy.config.k8s.io/v1alpha1 kind: KubeProxyConfiguration featureGates: IPv6DualStack: true clusterCIDR: 172.20.0.0/16 clientConnection: kubeconfig: /var/lib/kube-proxy/kubeconfig.conf conntrack: maxPerCore: 65536 mode: ipvs ipvs: scheduler: lc // Set scheduler to a proper scheduling algorithm. # Irrelevant fields are omitted.ACK専用クラスターを使用する場合は、kube-proxy-workerおよびkube-proxy-master ConfigMapsで、ipvs schedulerパラメーターを適切なスケジューリングアルゴリズムに設定します。 次に、kube-proxy-workerポッドとkube-proxy-masterポッドを削除します。 システムは、設定を有効にするためにポッドを自動的に再作成します。 kube-proxy-workerおよびkube-proxy-master ConfigMapsを変更し、それらのポッドを削除する方法の詳細については、kube-proxy設定を変更するにはどうすればよいですか? このトピックのセクション。
kube-proxyログを表示します。
kubectl get podsコマンドを実行して、kube-system名前空間のkube-proxy-workerコンテナーのステータスがRunningかどうかを確認します。 お使いのクラスターがACK専用クラスターの場合は、kube-proxy-masterコンテナーのステータスも確認する必要があります。
kubectl logsコマンドを実行して、コンテナーのログを表示します。
ログに [IPVSプロキシを使用できません: IPVSプロキシは、必要なカーネルモジュールが読み込まれないため使用されません: [ip_vs_lc]] が含まれている場合、IPVSカーネルモジュールは読み込まれません。 上記の手順がエラーなしで実行されたかどうかを確認してから、ログを再度クエリする必要があります。
ログにUsing iptables Proxier. が含まれている場合、kube-proxyはIPVSカーネルモジュールの有効化に失敗し、iptablesモードに戻ります。 この場合、kube-proxy設定をロールバックしてからノードを再起動することを推奨します。
ログに上記のメッセージが含まれておらず、Using ipvs Proxier. が含まれている場合、IPVSカーネルモジュールが有効になります。
kube-proxyが上記のチェックに合格すると、負荷分散アルゴリズムが変更されます。
kube-proxy設定でIPVS UDPセッションのタイムアウト期間を変更するにはどうすればよいですか。
クラスターでkube-proxyモードがIPVSに設定されている場合、IPVSのデフォルトのセッション永続化ポリシーにより、UDP接続が閉じられてから5分後にパケット損失が発生する可能性があります。 アプリケーションがCoreDNSに依存している場合、CoreDNSが更新された後、またはホストが再起動されてから5分後に、APIレイテンシやリクエストタイムアウトなどの問題が発生する場合があります。
クラスター内のアプリケーションがUDPプロトコルを使用していない場合は、IPVS UDPセッションのタイムアウト期間を短縮して、DNS解決の待ち時間や失敗の影響を最小限に抑えることができます。 これを行うには、次の操作を実行します。
アプリケーションがUDPを使用している場合、チケットを起票します。
ACKクラスターがKubernetes 1.18以降を実行する場合:
ACK管理クラスターを使用する場合は、kube-proxy-worker ConfigMapのudpTimeoutパラメーターを変更します。 次に、kube-proxy-workerポッドを削除します。 システムは、設定が有効になるようにポッドを自動的に再作成します。 kube-proxy-worker ConfigMapを変更してポッドを削除する方法の詳細については、kube-proxy設定を変更するにはどうすればよいですか? このトピックのセクション。
apiVersion: v1 kind: ConfigMap metadata: name: kube-proxy-worker namespace: kube-system data: config.conf: | apiVersion: kubeproxy.config.k8s.io/v1alpha1 kind: KubeProxyConfiguration # Irrelevant fields are omitted. mode: ipvs // If the ipvs field does not exist, you must add the field. ipvs: udpTimeout: 10s // The default timeout period is 300 seconds. In this example, the timeout period is set to 10 seconds. This way, the time period during which packet loss may occur is reduced to 10 seconds after a UDP connection is closed.ACK専用クラスターを使用する場合は、kube-proxy-workerおよびkube-proxy-master ConfigMapsのudpTimeoutパラメーターを変更します。 次に、kube-proxy-workerポッドとkube-proxy-masterポッドを削除します。 システムは、設定を有効にするためにポッドを自動的に再作成します。 kube-proxy-worker ConfigMapを変更してポッドを削除する方法の詳細については、kube-proxy設定を変更するにはどうすればよいですか? このトピックのセクション。
ACKクラスターがKubernetes 1.16以前を実行している場合:
Kubernetes 1.16以前を実行するACKクラスターのkube-proxyは、udpTimeoutパラメーターをサポートしていません。 UDPセッションのタイムアウト期間を変更するには、CloudOps Orchestration Service (OOS) を使用して、クラスター内のすべてのECSインスタンスで次の
ipvsadmコマンドを同時に実行することを推奨します。yum install -y ipvsadm ipvsadm -L --timeout > /tmp/ipvsadm_timeout_old ipvsadm --set 900 120 10 ipvsadm -L --timeout > /tmp/ipvsadm_timeout_new diff /tmp/ipvsadm_timeout_old /tmp/ipvsadm_timeout_newOOSを使用して複数のECSインスタンスを同時に管理する方法の詳細については、「一度に複数のインスタンスを管理する」をご参照ください。
IPv4/IPv6デュアルスタックに関連する一般的な問題を修正する方法?
問題の説明: kubectlに表示されるポッドのIPアドレスはまだIPv4アドレスです。
解決策: 次のコマンドを実行して、ポッドIPv6アドレスを表示します。
kubectl get pods -A -o jsonpath='{range .items[*]}{@.metadata.namespace} {@.metadata.name} {@.status.podIPs[*].ip} {"\n"}{end}'問題の説明: kubectlに表示されるクラスターIPアドレスはまだIPv4アドレスです。
解決策:
spec.ipFamilyPolicyフィールドがSingleStackに設定されていないことを確認します。
次のコマンドを実行して、クラスターIPv6アドレスを表示します。
kubectl get svc -A -o jsonpath='{range .items[*]}{@.metadata.namespace} {@.metadata.name} {@.spec.ipFamilyPolicy} {@.spec.clusterIPs[*]} {"\n"}{end}'
問題の説明: IPv6アドレスを使用してポッドにアクセスすることはできません。
原因: デフォルトでは、NGINXコンテナーなど、一部のアプリケーションはIPv6アドレスでリッスンしません。
解決策:
netstat -anpコマンドを実行して、ポッドがIPv6アドレスをリッスンするかどうかを確認します。期待される出力:
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 127.0.XX.XX:10248 0.0.0.0:* LISTEN 8196/kubelet tcp 0 0 127.0.XX.XX:41935 0.0.0.0:* LISTEN 8196/kubelet tcp 0 0 0.0.XX.XX:111 0.0.0.0:* LISTEN 598/rpcbind tcp 0 0 0.0.XX.XX:22 0.0.0.0:* LISTEN 3577/sshd tcp6 0 0 :::30500 :::* LISTEN 1916680/kube-proxy tcp6 0 0 :::10250 :::* LISTEN 8196/kubelet tcp6 0 0 :::31183 :::* LISTEN 1916680/kube-proxy tcp6 0 0 :::10255 :::* LISTEN 8196/kubelet tcp6 0 0 :::111 :::* LISTEN 598/rpcbind tcp6 0 0 :::10256 :::* LISTEN 1916680/kube-proxy tcp6 0 0 :::31641 :::* LISTEN 1916680/kube-proxy udp 0 0 0.0.0.0:68 0.0.0.0:* 4892/dhclient udp 0 0 0.0.0.0:111 0.0.0.0:* 598/rpcbind udp 0 0 47.100.XX.XX:323 0.0.0.0:* 6750/chronyd udp 0 0 0.0.0.0:720 0.0.0.0:* 598/rpcbind udp6 0 0 :::111 :::* 598/rpcbind udp6 0 0 ::1:323 :::* 6750/chronyd udp6 0 0 fe80::216:XXXX:fe03:546 :::* 6673/dhclient udp6 0 0 :::720 :::* 598/rpcbindProto列の値がtcpの場合、ポッドはIPv4アドレスをリッスンします。 値がtcp6の場合、ポッドはIPv6アドレスをリッスンします。問題の説明: クラスター内のIPv6アドレスを使用してポッドにアクセスできますが、インターネットからはアクセスできません。
原因: IPv6アドレスにパブリック帯域幅が設定されていません。
解決策: IPv6アドレスのパブリック帯域幅を設定します。 詳細については、「IPv6インターネット帯域幅の有効化と管理」をご参照ください。
問題の説明: クラスターIPv6アドレスを使用してポッドにアクセスすることはできません。
解決策:
spec.ipFamilyPolicyフィールドがSingleStackに設定されていないことを確認します。
netstat -anpコマンドを実行して、ポッドがIPv6アドレスをリッスンするかどうかを確認します。期待される出力:
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 127.0.XX.XX:10248 0.0.0.0:* LISTEN 8196/kubelet tcp 0 0 127.0.XX.XX:41935 0.0.0.0:* LISTEN 8196/kubelet tcp 0 0 0.0.XX.XX:111 0.0.0.0:* LISTEN 598/rpcbind tcp 0 0 0.0.XX.XX:22 0.0.0.0:* LISTEN 3577/sshd tcp6 0 0 :::30500 :::* LISTEN 1916680/kube-proxy tcp6 0 0 :::10250 :::* LISTEN 8196/kubelet tcp6 0 0 :::31183 :::* LISTEN 1916680/kube-proxy tcp6 0 0 :::10255 :::* LISTEN 8196/kubelet tcp6 0 0 :::111 :::* LISTEN 598/rpcbind tcp6 0 0 :::10256 :::* LISTEN 1916680/kube-proxy tcp6 0 0 :::31641 :::* LISTEN 1916680/kube-proxy udp 0 0 0.0.0.0:68 0.0.0.0:* 4892/dhclient udp 0 0 0.0.0.0:111 0.0.0.0:* 598/rpcbind udp 0 0 47.100.XX.XX:323 0.0.0.0:* 6750/chronyd udp 0 0 0.0.0.0:720 0.0.0.0:* 598/rpcbind udp6 0 0 :::111 :::* 598/rpcbind udp6 0 0 ::1:323 :::* 6750/chronyd udp6 0 0 fe80::216:XXXX:fe03:546 :::* 6673/dhclient udp6 0 0 :::720 :::* 598/rpcbindProto列の値がtcpの場合、ポッドはIPv4アドレスをリッスンします。 値がtcp6の場合、ポッドはIPv6アドレスをリッスンします。問題の説明: IPv6アドレスを使用してポッドからインターネットにアクセスすることはできません。
解決策: ポッドが存在するVPCのIPv6ゲートウェイを作成し、使用するIPv6アドレスのパブリック帯域幅を設定します。 詳細については、「IPv6ゲートウェイの作成と管理」および「IPv6インターネット帯域幅の有効化と管理」をご参照ください。
Terwayと共にインストールされたACKクラスターのアイドル状態のvSwitch IPアドレスが不十分な場合はどうすればよいですか?
問題の説明
ポッドの作成に失敗しました。 VPCコンソールにログインした後、ポッドを作成するリージョンを選択し、左側のナビゲーションウィンドウでvSwitchをクリックしてvSwitchページに移動すると、vSwitchの使用可能なIPアドレスの数が0であることがわかります。 この問題のトラブルシューティング方法の詳細については、このトピックの「次の作業」セクションを参照してください。
原因
ノードのTerwayネットワークで使用されるvSwitchには、十分なアイドルIPアドレスがありません。 その結果、作成するポッドにIPアドレスは割り当てられず、ポッドはContainerCreating状態のままです。
解決策
次の手順を実行して、別のvSwitchを追加します。
VPCコンソールにログインし、上部のナビゲーションバーでリージョンを選択し、vSwitchを作成します。
説明作成するvSwitchは、十分なアイドルIPアドレスがないvSwitchのリージョンとゾーンに存在する必要があります。 ポッドの数が増え続ける場合は、ポッドのvSwitch CIDRブロックのマスク長を19以下の値に設定することを推奨します。 これにより、CIDRブロックに少なくとも8,192のIPアドレスが含まれます。
次のいずれかのコマンドを実行して、すべてのTerwayポッドを削除します。 次に、システムはTerwayポッドを再作成します。
説明クラスターの作成時にTerwayを選択し、[各ポッドに1つのENIを割り当てる] を選択した場合、ENIには1つのIPアドレスしかありません。 このオプションを選択しない場合、ENIには複数のIPアドレスがあります。 詳細については、「Terwayでの作業」をご参照ください。
ENIが複数のIPアドレスを使用している場合は、次のコマンドを実行します。
kubectl delete -n kube-system pod -l app=terway-eniip。ENIが1つのIPアドレスのみを使用する場合は、次のコマンドを実行します。
kubectl delete -n kube-system pod -l app=terway-eni
kubectl get podコマンドを実行して、すべてのTerwayポッドが再作成されていることを確認します。ポッドを作成します。 ポッドが作成され、IPアドレスがvSwitchからポッドに割り当てられていることを確認します。
次に何をすべきか
ACKクラスターに接続し、
kubectl get podコマンドを実行します。 出力は、ポッドがContainerCreating状態であることを示します。 ACKクラスターに接続する方法の詳細については、「クラスターのkubeconfigファイルを取得し、kubectlを使用してクラスターに接続する」をご参照ください。 次のコマンドを実行して、ポッドをホストするノードのTerwayコンテナログを印刷します。kubectl get pod -l app=terway-eniip -n kube-system | grep [$Node_Name] # [$Node_Name] indicates the name of the node that hosts the pod. You can use the node name to identify the Terway pod on the node. kubectl logs --tail=100 -f [$Pod_Name] -n kube-system -c terway # [$Pod_Name] indicates the name of the Terway pod on the node.InvalidVSwitchId.IpNotEnoughエラーメッセージが表示された場合、vSwitchには十分なアイドルIPアドレスがありません。
time="2020-03-17T07:03:40Z" level=warning msg="Assign private ip address failed: Aliyun API Error: RequestId: 2095E971-E473-4BA0-853F-0C41CF52651D Status Code: 403 Code: InvalidVSwitchId.IpNotEnough Message: The specified VSwitch \"vsw-AAA\" has not enough IpAddress., retrying"
新しく作成されたポッドのIPアドレスがTerwayモードのvSwitch CIDRブロックに含まれない場合はどうすればよいですか?
問題の説明
Terwayモードでは、新しく作成されたポッドのIPアドレスはvSwitch CIDRブロックに含まれません。
原因
ポッドが作成された後、ECSインスタンスのENIはVPC CIDRブロックからポッドにIPアドレスを割り当てます。 vSwitchは、新しく作成されたENIがノードに接続されている場合にのみ設定できます。 ノードをクラスターに追加する前、またはTerwayが使用するvSwitchを変更する前に、ENIがノードにアタッチされている場合、ENIは、ENIが属するvSwitchからノードに新しく作成されたポッドにIPアドレスを割り当てます。
この問題は、次のシナリオで発生する可能性があります。
別のクラスターから削除されたノードをクラスターに追加します。 ノードは取り外される前に排水されませんでした。 この場合、ノードは、ノードが以前に属していたクラスターによってアタッチされたENIを使用します。
Terwayで使用されるvSwitchを手動で追加または変更します。 しかしながら、ノードは、依然として元のENIにアタッチされ得る。 この場合、ENIは、ENIが属するvSwitchからノード上に新しく作成されたポッドにIPアドレスを割り当てます。
解決策
新しいノードを作成できます。 クラスターからノードを削除し、削除したノードをクラスターに追加することもできます。
ノードを削除し、削除したノードを追加するには、次の手順を実行します。
ノードをドレインして削除します。 詳細については、「ノードの削除」をご参照ください。
削除されたノードからENIの関連付けを解除します。 詳細については、「セカンダリENIのバインド解除」をご参照ください。
削除されたノードをACKクラスターに追加します。 詳細については、「既存のECSインスタンスをACKクラスターに追加する」をご参照ください。
TerwayモードでvSwitchを追加した後、新しく作成されたポッドのIPアドレスがvSwitch CIDRブロックに含まれない場合はどうすればよいですか?
問題の説明
Terwayモードでは、vSwitchを追加した後、新しく作成されたポッドのIPアドレスがvSwitch CIDRブロックに含まれません。
原因
ポッドが作成された後、ECSインスタンスのENIはVPC CIDRブロックからポッドにIPアドレスを割り当てます。 vSwitchは、新しく作成されたENIがノードに接続されている場合にのみ設定できます。 ノードをクラスターに追加する前、またはTerwayが使用するvSwitchを変更する前に、ENIがノードにアタッチされている場合、ENIは、ENIが属するvSwitchからノードに新しく作成されたポッドにIPアドレスを割り当てます。 ただし、ノードにアタッチされているENIの数が上限に達し、新しいENIを作成できません。 その結果、このエラーが発生します。 ENIクォータの詳細については、「概要」をご参照ください。
解決策
新しいノードを作成できます。 クラスターからノードを削除し、削除したノードをクラスターに追加することもできます。
ノードを削除し、削除したノードを追加するには、次の手順を実行します。
ノードをドレインして削除します。 詳細については、「ノードの削除」をご参照ください。
削除されたノードからENIの関連付けを解除します。 詳細については、「セカンダリENIのバインド解除」をご参照ください。
削除されたノードをACKクラスターに追加します。 詳細については、「既存のECSインスタンスをACKクラスターに追加する」をご参照ください。
Terway IPVLANモードでクラスター内の負荷分散を有効にするにはどうすればよいですか?
問題の説明
Terway IPVLANモードでは、Terway 1.2.0以降を使用するクラスターを作成すると、クラスター内で負荷分散が自動的に有効になります。 クラスター内の外部IPアドレスまたはServer Load Balancer (SLB) インスタンスにアクセスすると、トラフィックはバックエンドサービスにルーティングされます。
原因
クラスター内の外部IPアドレスまたはSLBインスタンスにアクセスする場合、kube-proxyはトラフィックをバックエンドサービスのエンドポイントに直接ルーティングします。 Terway IPVLANモードでは、トラフィックはkube-proxyではなくCiliumによって処理されます。 この機能は、1.2.0以前のバージョンではサポートされていません。 この機能は、Terway 1.2.0以降のバージョンを使用するクラスターで自動的に有効になります。 1.2.0より前のバージョンのTerwayを使用するクラスターでは、この機能を手動で有効にする必要があります。
解決策
Terwayを1.2.0以降に更新し、IPVLANモードを有効にします。
IPVLANモードが有効になっていない場合、次の設定は有効になりません。
この機能は、Terway 1.2.0以降のバージョンを使用する新しく作成されたクラスターで自動的に有効になります。
次のコマンドを実行して、Terway設定のeni_conf ConfigMapを変更します。
kubectl edit cm eni-config -n kube-system次のコンテンツをeni_conf ConfigMapに追加します。
in_cluster_loadbalance: "true"説明in_cluster_loadbalanceがeni_confと一致していることを確認します。次のコマンドを実行して、Terwayポッドを再作成してクラスター内の負荷分散を有効にします。
kubectl delete pod -n kube-system -l app=terway-eniip設定の確認
次のコマンドを実行して、policyログをterway-ennipに出力します。
enable-in-cluster-loadbalance=trueがログに表示されている場合、変更は有効です。kubectl logs -n kube-system <terway pod name> policy | grep enable-in-cluster-loadbalance
クラスターがTerwayを使用している場合、ポッドCIDRブロックをホワイトリストに追加する方法を教えてください。
問題の説明
ホワイトリストを使用して、データベースサービスなどのサービスに対してアクセス制御を適用します。 コンテナネットワークでアクセス制御を構成するには、ポッドIPアドレスをホワイトリストに追加する必要があります。 ただし、ポッドのIPアドレスは動的に変更されます。
原因
ACKは、コンテナネットワークを設定するためのFlannelおよびTerwayネットワークプラグインを提供します。
クラスターがFlannelを使用している場合、クラスター内のポッドは、ポッドをホストするノードのIPアドレスを使用して、データベースサービスなどのサービスにアクセスします。 クライアントポッドを少数のノードにスケジュールしてから、これらのノードのIPアドレスをデータベースサービスのホワイトリストに追加できます。
クラスターがTerwayを使用している場合、ENIはクラスター内のポッドにIPアドレスを割り当てます。 ポッドは、ENIによって割り当てられたIPアドレスを使用して外部サービスにアクセスします。 したがって、アフィニティ設定に基づいて特定のノードにクライアントポッドをスケジュールしても、クライアントポッドはノードのIPアドレスを使用して外部サービスにアクセスすることはありません。 ランダムなIPアドレスは、Terwayで指定されたvSwitchからポッドに割り当てられます。 ほとんどの場合、ポッドには自動スケーリングが必要です。 したがって、静的IPアドレスはポッドには適していません。 自動スケーリングの要件を満たすには、ポッドにCIDRブロックを指定してから、アクセスするデータベースサービスのホワイトリストにCIDRブロックを追加することをお勧めします。
解決策
ノードにラベルを追加して、ポッドにIPアドレスを割り当てるために使用されるvSwitchを指定します。 このようにして、ポッドが指定されたラベルを持つノードにスケジュールされると、システムはvSwitchを使用してポッドにIPアドレスを割り当てます。
kube-system名前空間にeni-config-fixedという名前のConfigMapを作成します。 ConfigMapで使用するvSwitchを指定します。
この例では、vsw-2zem796p76viir02c **** vSwitchが使用されています。 vSwitchのCIDRブロックは10.2.1.0/24です。
apiVersion: v1 data: eni_conf: | { "vswitches": {"cn-beijing-h":["vsw-2zem796p76viir02c****"]}, "security_group": "sg-bp19k3sj8dk3dcd7****", "security_groups": ["sg-bp1b39sjf3v49c33****","sg-bp1bpdfg35tg****"] } kind: ConfigMap metadata: name: eni-config-fixed namespace: kube-systemノードプールを作成し、terway-config: eni-config-fixedラベルをノードプール内のノードに追加します。 ノードプールの作成方法の詳細については、「ノードプールの作成」トピックのProcedureセクションを参照してください。
無関係なポッドがノードプール内のノードにスケジュールされないようにするには、特定のテイントを追加します。 たとえば、
fixed=true:NoScheduleテイントをノードに追加できます。
ノードプールをスケールアウトします。 詳細については、「ACKクラスター内のノード数の増加」をご参照ください。
前の手順で追加したラベルとテイントは、ノードプールに新しく追加されたノードに自動的に追加されます。
ポッドを作成します。 ポッドが
terway-config: eni-config-fixedラベルを持つノードにスケジュールされるようにするには、ポッド構成に特定の許容範囲ルールを追加する必要があります。apiVersion: apps/v1 # Use apps/v1beta1 in clusters that run Kubernetes 1.8.0 or earlier. kind: Deployment metadata: name: nginx-fixed labels: app: nginx-fixed spec: replicas: 2 selector: matchLabels: app: nginx-fixed template: metadata: labels: app: nginx-fixed spec: tolerations: # Add a toleration rule. - key: "fixed" operator: "Equal" value: "true" effect: "NoSchedule" nodeSelector: terway-config: eni-config-fixed containers: - name: nginx image: nginx:1.9.0 # Replace the value with the actual image that you use. Format: <image_name:tags>. ports: - containerPort: 80Verify the result
次のコマンドを実行して、作成したポッドのIPアドレスを照会します。
kubectl get po -o wide | grep fixed期待される出力:
nginx-fixed-57d4c9bd97-l**** 1/1 Running 0 39s 10.2.1.124 bj-tw.062149.aliyun.com <none> <none> nginx-fixed-57d4c9bd97-t**** 1/1 Running 0 39s 10.2.1.125 bj-tw.062148.aliyun.com <none> <none>出力は、指定したvSwitchからポッドのIPアドレスが割り当てられていることを示します。
次のコマンドを実行して、ポッドの数を30に増やします。
kubectl scale deployment nginx-fixed --replicas=30期待される出力:
nginx-fixed-57d4c9bd97-2**** 1/1 Running 0 60s 10.2.1.132 bj-tw.062148.aliyun.com <none> <none> nginx-fixed-57d4c9bd97-4**** 1/1 Running 0 60s 10.2.1.144 bj-tw.062149.aliyun.com <none> <none> nginx-fixed-57d4c9bd97-5**** 1/1 Running 0 60s 10.2.1.143 bj-tw.062148.aliyun.com <none> <none> ...出力は、指定したvSwitchからポッドのIPアドレスが割り当てられていることを示します。 vSwitchのCIDRブロックを、アクセスするデータベースサービスのホワイトリストに追加できます。 これにより、動的IPアドレスを使用するポッドに対してアクセス制御が適用されます。
新しいノードを作成することを推奨します。 既存のノードを使用する場合、ECSインスタンスをクラスターに追加する前に、ECSインスタンスからENIの関連付けを解除する必要があります。 自動モードで既存のノードを追加する必要があります。 自動モードでは、ノードのシステムディスクが交換されます。 詳細については、「セカンダリENIのバインド解除」および「ノードの自動追加」をご参照ください。
クライアントポッドのホストに使用するノードプール内のノードに、特定のラベルとテイントを追加する必要があります。 これにより、無関係なポッドがノードプールにスケジュールされなくなります。
eni-config-fixed ConfigMapを作成すると、eni-config ConfigMapが上書きされます。 eni-config ConfigMapの設定方法の詳細については、「terway」をご参照ください。
クライアントポッドの少なくとも2倍のIPアドレスを提供できるvSwitchを指定することをお勧めします。 これにより、ポッドがスケールアウトされたり、IPアドレスが再利用できない場合に十分なIPアドレスが保証されます。
ポッドからECSノードへのpingに失敗した場合はどうすればよいですか。
問題の説明
クラスターはFlannelを使用し、VPNゲートウェイは期待どおりに機能します。 ポッドにログインした後、特定のECSノードのpingに失敗します。
原因
次の原因により、特定のECSノードのpingに失敗することがあります。
原因1: ポッドからアクセスするECSインスタンスは、ポッドがデプロイされているクラスターと同じVPCにデプロイされていますが、クラスターと同じセキュリティグループに属していません。
原因2: ポッドからアクセスするECSインスタンスが、ポッドがデプロイされているクラスターと同じVPCにデプロイされていません。
解決策
原因に基づいて問題を解決します。
問題が原因1の場合、クラスターが属するセキュリティグループにECSインスタンスを追加する必要があります。 詳細については、「セキュリティグループの設定」をご参照ください。
問題が原因2の場合、ポッドがデプロイされているクラスターのパブリックIPアドレスを、ECSインスタンスが属するセキュリティグループのインバウンドルールに追加する必要があります。
ノードにNodeNetworkUnavailableテイントがある場合はどうすればよいですか?
問題の説明
Flannelを使用するクラスターでは、新しく追加されたノードにNodeNetworkUnavailableテイントがあり、ポッドをそのノードにスケジュールすることはできません。
原因
NodeNetworkUnavailableテイントは、ルートテーブルがいっぱいになったり、複数のルートテーブルがあるVPCなどの理由で、クラウドコントローラマネージャ (CCM) によって削除されません。
解決策
kubectl describe nodeコマンドを実行して、ノードイベントを確認し、返されたエラーメッセージに基づいて問題を修正します。 CCMを使用して複数のルートテーブルを設定する方法の詳細については、「VPCの複数のルートテーブルの設定」をご参照ください。
ポッドの起動に失敗し、「範囲内で使用可能なIPアドレスはありません」というエラーメッセージが表示された場合はどうすればよいですか?
問題の説明
Flannelネットワークでポッドを起動できず、failed to allocate for range 0: no IP addresses available in range set: 172.30.34.129-172.30.34.190エラーメッセージが関連するポッドイベントに表示されます。
原因
解決策
クラスターのKubernetesバージョンが1.20より前の場合は、Kubernetesバージョンを1.20以降に更新します。 詳細については、「クラスターの手動更新」をご参照ください。
クラスターで使用されているFlannelプラグインのバージョンが0.15.1.11-7e95fe23-aliyunより前の場合は、次の手順を実行してFlannelプラグインを0.15.1.11-7e95fe23-aliyun以降に更新します。
お使いのクラスターがFlannel 0.15.1.11-7e95fe23-aliyun以降を使用している場合、ACKはデフォルトのCIDRブロックを格納するデータベースを一時ディレクトリ /var/runに移行します。 ノードが再起動されると、システムは一時ディレクトリ内のデータを自動的に削除して、一時ディレクトリ内のIPアドレスの漏洩を防ぎます。
フランネルを0.15.1.11-7e95fe23-aliyun以降に更新します。 詳細については、「コンポーネントの管理」をご参照ください。
次のコマンドを実行して、kube-flannel-cfgファイルを変更します。 dataDirおよびipamパラメーターをkube-flannel-cfgファイルに追加します。
kubectl -n kube-system edit cm kube-flannel-cfgサンプルkube-flannel-cfgファイル:
# The original settings { "name": "cb0", "cniVersion":"0.3.1", "plugins": [ { "type": "flannel", "delegate": { "isDefaultGateway": true, "hairpinMode": true }, }, // portmap # This configuration may not be used in earlier versions of Flannel. You ignore this configuration if it is not required. { "type": "portmap", "capabilities": { "portMappings": true }, "externalSetMarkChain": "KUBE-MARK-MASQ" } ] } # The modified settings { "name": "cb0", "cniVersion":"0.3.1", "plugins": [ { "type": "flannel", "delegate": { "isDefaultGateway": true, "hairpinMode": true }, // Add a comma (,) to the end of each parameter. "dataDir": "/var/run/cni/flannel", "ipam": { "type": "host-local", "dataDir": "/var/run/cni/networks" } }, { "type": "portmap", "capabilities": { "portMappings": true }, "externalSetMarkChain": "KUBE-MARK-MASQ" } ] }次のコマンドを実行して、Flannelポッドを再起動します。
再起動操作は、実行中のワークロードを中断しません。
kubectl -n kube-system delete pod -l app=flannelノード上のCIDRブロックを格納するディレクトリを削除し、ノードを再起動します。
ドレインノード。 詳細については、「ノードのスケジューリング可能性の設定」をご参照ください。
各ノードにログインし、次のコマンドを実行して、CIDRブロックが格納されているディレクトリを削除します。
rm -rf /etc/cni/ rm -rf /var/lib/cni/ノードを再起動します。 詳細は、「インスタンスの再起動」をご参照ください。
上記の手順を繰り返して、クラスター内のすべてのノードのCIDRブロックを格納するディレクトリを削除します。
次のコマンドを実行して、CIDRブロックを格納するノードに一時ディレクトリが作成されているかどうかを確認します。
if [ -d /var/lib/cni/networks/cb0 ]; then echo "not using tmpfs"; fi if [ -d /var/run/cni/networks/cb0 ]; then echo "using tmpfs"; fi cat /etc/cni/net.d/10-flannel.conf*using tmpfsが返された場合、現在のノードは、デフォルトのCIDRブロックを格納するデータベースを一時ディレクトリ /var/runに移行しています。
クラスターのKubernetesバージョンまたはクラスターで使用されているFlannelプラグインを短期間で更新できない場合は、一時的な解決策として次の方法を使用できます。 次の方法は、上記の理由で発生したポッドIPアドレスリークにのみ適用されます。
このメソッドは、漏洩したポッドIPアドレスを削除するために使用されます。 この方法を使用して、ポッドIPアドレスのリークを防ぐことはできません。 したがって、クラスターのKubernetesバージョンまたはクラスターで使用されるFlannelプラグインをできるだけ早く更新する必要があります。
説明次のコマンドは、Flannel 0.15.1.11-7e95fe23-aliyun以降を使用し、CIDRブロックを /var/runディレクトリに格納しているノードには適用できません。
次のスクリプトは参考用です。 カスタムノード設定を設定した場合、スクリプトの実行に失敗する可能性があります。
ポッドのIPアドレスが漏洩しているノードをUnschedulableに設定します。 詳細については、「ノードのスケジューリング可能性の設定」をご参照ください。
ノードが使用するコンテナランタイムに基づいてスクリプトを選択し、ノードでスクリプトを実行して、リークされたポッドIPアドレスを削除します。
ノードがDockerを使用している場合は、ノードで次のスクリプトを実行して、漏洩したポッドIPアドレスを削除します。
#!/bin/bash cd /var/lib/cni/networks/cb0; docker ps -q > /tmp/running_container_ids find /var/lib/cni/networks/cb0 -regex ".*/[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+" -printf '%f\n' > /tmp/allocated_ips for ip in $(cat /tmp/allocated_ips); do cid=$(head -1 $ip | sed 's/\r#g' | cut -c-12) grep $cid /tmp/running_container_ids > /dev/null || (echo removing leaked ip $ip && rm $ip) doneノードがcontainerdを使用している場合は、ノードで次のスクリプトを実行して、漏洩したポッドIPアドレスを削除します。
#!/bin/bash # install jq yum install -y jq # export all running pod's configs crictl -r /run/containerd/containerd.sock pods -s ready -q | xargs -n1 crictl -r /run/containerd/containerd.sock inspectp > /tmp/flannel_ip_gc_all_pods # export and sort pod ip cat /tmp/flannel_ip_gc_all_pods | jq -r '.info.cniResult.Interfaces.eth0.IPConfigs[0].IP' | sort > /tmp/flannel_ip_gc_all_pods_ips # export flannel's all allocated pod ip ls -alh /var/lib/cni/networks/cb0/1* | cut -f7 -d"/" | sort > /tmp/flannel_ip_gc_all_allocated_pod_ips # print leaked pod ip comm -13 /tmp/flannel_ip_gc_all_pods_ips /tmp/flannel_ip_gc_all_allocated_pod_ips > /tmp/flannel_ip_gc_leaked_pod_ip # clean leaked pod ip echo "Found $(cat /tmp/flannel_ip_gc_leaked_pod_ip | wc -l) leaked Pod IP, press <Enter> to clean." read sure # delete leaked pod ip for pod_ip in $(cat /tmp/flannel_ip_gc_leaked_pod_ip); do rm /var/lib/cni/networks/cb0/${pod_ip} done echo "Leaked Pod IP cleaned, removing temp file." rm /tmp/flannel_ip_gc_all_pods_ips /tmp/flannel_ip_gc_all_pods /tmp/flannel_ip_gc_leaked_pod_ip /tmp/flannel_ip_gc_all_allocated_pod_ips
ノードをSchedulableに設定します。 詳細については、「ノードのスケジューリング可能性の設定」をご参照ください。
ノードIPアドレス、ポッドCIDRブロック、およびService IPブロックの数を変更するにはどうすればよいですか。
クラスターのノードIPアドレス、ポッドCIDRブロック、およびService IPブロックの数は、クラスターの作成後に変更することはできません。 クラスターの作成時にこれらの項目を適切に設定することを推奨します。
どのようなシナリオでクラスターに複数のルートテーブルを設定する必要がありますか?
Flannelを使用するクラスターでは、次のシナリオで複数のルートテーブルが一般的に使用されます。
シナリオ
シナリオ 1：
ポッドのCIDRブロックがVPCのルートテーブルにないことを示すシステム診断情報が表示され、CIDRブロックのネクストホップを現在のノードに追加するカスタムルートをカスタムルートテーブルに追加する必要があります。
原因: クラスターにカスタムルートテーブルを作成する場合、複数のルートテーブルをサポートするようにCCMを設定する必要があります。
シナリオ 2：
cloud-controller-managerコンポーネントは、ネットワークエラーが原因で
複数のルートテーブルが見つかったことを示すエラーを報告します。原因: クラスターに複数のルートテーブルがある場合、複数のルートテーブルをサポートするようにCCMを設定する必要があります。
シナリオ 3：
Flannelを使用するクラスターで、新しく追加されたノードにNodeNetworkUnavailableテイントがある場合、このテイントはcloud-controller-managerコンポーネントによって削除されません。 その結果、ポッドをノードにスケジュールすることはできません。 詳細については、「」をご参照ください。ノードにNodeNetworkUnavailableテイントがある場合はどうすればよいですか?.
クラスターにサードパーティのネットワークプラグインをインストールして設定できますか。
いいえ、ACKクラスター用のサードパーティ製ネットワークプラグインをインストールまたは設定することはできません。 ACKクラスターにサードパーティのネットワークプラグインがインストールされている場合、クラスターネットワークが利用できなくなることがあります。
「範囲セットで使用可能なIPアドレスはありません」というエラーメッセージが表示された場合はどうすればよいですか?
このエラーは、クラスターで使用されているTerwayまたはFlannelネットワークプラグインが古いために表示されることがあります。 TerwayまたはFlannelは、クラスターのポッドCIDRブロックを定義します。これは、制限付きIPアドレスを各ノードのポッドに割り当てるために使用されます。 この範囲のすべてのIPアドレスが割り当てられている場合、一部のIPアドレスがリリースされるか、クラスタネットワークが再構築または拡張されない限り、このノードに新しいポッドを作成できません。 この問題を解決するには、クラスターにインストールされているTerwayプラグインを最新バージョンに更新します。
Terwayモードでノードに作成できるポッドの数はいくつですか?
Terwayモードでは、ノードに作成できるポッドの数は、ECSインスタンスタイプに基づく使用可能なIPアドレスの数によって異なります。 詳細については、「Terwayでの作業」トピックのTerwayでの作業セクションを参照してください。
Terway DataPath V2とは何ですか?
Terway 1.8.0以降を使用してDataPath V2を選択してクラスターを作成した場合、デフォルトでDataPath V2モードが有効になっています。 IPVLAN機能を有効にした既存のクラスターでは、元のIPVLANモードがデータプレーンで使用されます。
DataPathV2は、次世代のデータプレーンパスである。 IPVLANモードと比較して、DataPath V2モードはより良い互換性を提供します。 詳細については、「Terwayでの作業」をご参照ください。
Terwayモードでポッドのライフサイクルを表示するにはどうすればよいですか?
ACKコンソールにログインします。 左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、管理するクラスターの名前をクリックします。 左側のウィンドウで、 を選択します。
DaemonSetsページの上部で、
アイコンをクリックして、名前空間ドロップダウンリストからkube-systemを選択します。 DaemonSetsページで、terway-eniipを検索し、[名前] 列のterway-eniipをクリックします。
次の表に、ポッドのステータスを示します。
ステータス
説明
実行中
ポッド内のすべてのコンテナが起動され、期待どおりに実行されます。
保留中
ポッドは、Terwayがネットワークリソースを構成するのを待っています。
リソースが不足しているため、特定のノードにポッドをスケジュールできません。 詳細については、「ポッドのトラブルシューティング」トピックの「ポッドは保留中」セクションをご参照ください。
ContainerCreating
ポッドは特定のノードにスケジュールされています。 これは、ポッドがネットワーク初期化の完了を待っていることを示します。
詳細については、「ポッドのライフサイクル」をご参照ください。
Terwayの更新の失敗のトラブルシューティング
問題 | 解決策 |
更新中に | Elastic IPアドレス (EIP) の機能は、Terwayではサポートされなくなりました。 この機能を引き続き使用する方法の詳細については、「Terwayからack-extend-network-controllerへのEIPの移行」をご参照ください。 |
Terwayモードでポッド作成中にMACアドレスが見つからない場合はどうすればよいですか?
問題の説明
MACアドレスが見つからないことを示すエラーのため、ポッドの作成に失敗しました。
failed to do add; error parse config, can't found dev by mac 00:16:3e:xx:xx:xx: not found解決策
ネットワークインターフェースカード (NIC) はシステム内で非同期にロードされ、CNIの設定時に完全にロードされない場合があります。 この場合、CNIは自動的に再試行され、システムに影響はありません。 ポッドが作成されているかどうかは、ポッドの最終ステータスを確認して確認できます。
長時間経過した後に前述のエラーでポッドの作成に失敗した場合は、インスタンスを再起動して問題を解決できます。 ほとんどの場合、この問題は、上位メモリが不足しており、NICのアタッチ処理中にドライバが読み込まれないために発生します。 上位メモリとは、ページと呼ばれるメモリ割り当ての最小単位よりも大きいメモリブロックを指します。ページのサイズは通常4KBです。