このトピックでは、Terway または Flannel ネットワークプラグインを使用する際に発生する可能性のある一般的な問題と、その解決方法について説明します。たとえば、このトピックでは、ネットワークプラグインの選択方法、クラスターにサードパーティのネットワークプラグインをインストールできるかどうか、クラスターネットワークの計画方法などの質問に回答します。
インデックス
Terway
Terway DataPathv2 または IPvlan+eBPF モードのルーティングは IPVS をバイパスしますか？
Terway ネットワークモードで vSwitch を追加した後、クラスターがインターネットにアクセスできない場合はどうすればよいですか？
Terway ネットワークモードの Pod に vSwitch CIDR ブロックにない IP アドレスが割り当てられた場合はどうすればよいですか？
Terway ネットワークモードで vSwitch をスケールアウトした後も Pod に IP アドレスを割り当てることができない場合はどうすればよいですか？
Kubernetes クラスター用の Terway と Flannel ネットワークプラグインのどちらを選択すればよいですか？
Flannel
kube-proxy
IPv6
その他
Terway の主なネットワークモードは何ですか？
Terway には、共有 Elastic Network Interface (ENI) モードと排他的な ENI モードの 2 つの主要なネットワークモードがあります。詳細については、共有 ENI モードと排他的な ENI モードをご参照ください。Terway の共有 ENI モードのみがネットワークアクセラレーション (DataPathv2 または IPvlan+eBPF) をサポートしていることに注意してください。DataPathv2 は、IPvlan+eBPF アクセラレーションモードのアップグレードバージョンです。Terway v1.8.0 以降では、クラスターを作成して Terway プラグインをインストールする際に、DataPathv2 が唯一利用可能なアクセラレーションオプションです。
Terway が排他的な ENI モードか共有 ENI モードかを確認する方法
Terway v1.11.0 以降では、Terway はデフォルトで共有 ENI モードを使用します。ノードプールの排他的な ENI ネットワークモードを設定することで、排他的な ENI モードを有効にできます。
Terway v1.11.0 より前のバージョンでは、クラスターの作成時に排他的または共有 ENI モードのいずれかを選択できます。クラスターが作成された後、次のようにモードを識別できます。
排他的な ENI モード: kube-system 名前空間の Terway DaemonSet の名前は
terway-eniです。共有 ENI モード: kube-system 名前空間の Terway DaemonSet の名前は
terway-eniipです。
Terway ネットワークアクセラレーションが DataPathv2 か IPvlan+eBPF かを確認する方法
Terway の共有 ENI モードのみがネットワークアクセラレーション (DataPathv2 または IPvlan+eBPF) をサポートしています。DataPathv2 は、IPvlan+eBPF アクセラレーションモードのアップグレードバージョンです。Terway v1.8.0 以降では、クラスターを作成して Terway プラグインをインストールする際に、DataPathv2 が唯一利用可能なアクセラレーションオプションです。
kube-system 名前空間の eni-config ConfigMap の eniip_virtual_type 構成をチェックして、ネットワークアクセラレーションが有効になっているかどうかを判断できます。値は datapathv2 または ipvlan です。
Terway DataPathv2 または IPvlan+eBPF モードのルーティングは IPVS をバイパスしますか？
Terway のアクセラレーションモード (DataPathv2 または IPvlan+eBPF) を有効にすると、通常の共有 ENI モードとは異なるトラフィック転送パスが使用されます。Pod が内部サービスにアクセスする場合など、特定のシナリオでは、トラフィックはノードのネットワークプロトコルスタックをバイパスし、ノードの IPVS ルートを通過する必要がありません。代わりに、eBPF がサービスアドレスをバックエンド Pod のアドレスに解決します。トラフィックフローの詳細については、「ネットワークアクセラレーション」をご参照ください。
既存の ACK クラスターのネットワークプラグインを切り替えることはできますか？
ネットワークプラグイン (Terway または Flannel) は、クラスターの作成時にのみ選択できます。クラスターの作成後にネットワークプラグインを変更することはできません。別のネットワークプラグインを使用するには、新しいクラスターを作成する必要があります。詳細については、「ACK マネージドクラスターを作成する」をご参照ください。
Terway ネットワークモードで vSwitch を追加した後、クラスターがインターネットにアクセスできない場合はどうすればよいですか？
症状
Pod の IP リソースが不足したため、手動で vSwitch を追加します。vSwitch を追加した後、クラスターがインターネットにアクセスできないことがわかります。
原因
Pod に IP アドレスを提供する vSwitch がインターネットにアクセスできません。
解決策
NAT Gateway の SNAT 機能を使用して、Pod に IP アドレスを提供する vSwitch の SNAT ルールを構成できます。詳細については、「クラスターのインターネットアクセスを有効にする」をご参照ください。
バージョン 1.16 以降のクラスターで Flannel イメージバージョンを手動でアップグレードした後の非互換性の問題を解決する方法
症状
クラスターをバージョン 1.16 にアップグレードした後、クラスターノードが NotReady 状態になります。
原因
この問題は、Flannel バージョンを手動でアップグレードしましたが、Flannel 構成をアップグレードしなかったために発生します。その結果、kubelet は新しい構成を認識できません。
解決策
Flannel 構成を編集して
cniVersionフィールドを追加します。kubectl edit cm kube-flannel-cfg -n kube-system構成に
cniVersionフィールドを追加します。"name": "cb0", "cniVersion":"0.3.0", "type": "flannel",Flannel を再起動します。
kubectl delete pod -n kube-system -l app=flannel
Pod の起動後のレイテンシーの問題を解決する方法
症状
Pod が起動した後、ネットワークが利用可能になるまでに遅延が発生します。
原因
構成されたネットワークポリシーが遅延を引き起こす可能性があります。ネットワークポリシーを無効にすると、この問題が解決する場合があります。
解決策
Terway ConfigMap を変更して、NetworkPolicy を無効にする構成を追加します。
kubectl edit cm -n kube-system eni-config構成に次のフィールドを追加します。
disable_network_policy: "true"オプション:最新バージョンの Terway を使用していない場合は、コンソールでアップグレードします。
ACK コンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
クラスター ページで、目的のクラスターを見つけてその名前をクリックします。左側のペインで、 を選択します。
アドオン管理 ページで、ネットワーク タブをクリックし、Terway コンポーネントの [アップグレード] をクリックします。
表示されるダイアログボックスで、プロンプトに従って構成を完了し、OK をクリックします。
すべての Terway Pod を再起動します。
kubectl delete pod -n kube-system -l app=terway-eniip
Pod が公開するサービスにアクセスできるようにする方法
症状
Pod が公開するサービスにアクセスできません。Pod が自身にスケジュールされると、アクセスが断続的になるか失敗します。
原因
これは、Flannel クラスターでループバックアクセスが有効になっていないために発生する可能性があります。
v0.15.1.4-e02c8f12-aliyun より前の Flannel バージョンでは、ループバックアクセスは許可されていません。アップグレード後も、ループバックアクセスはデフォルトで無効のままですが、手動で有効にできます。
ループバックアクセスは、Flannel v0.15.1.4-e02c8f12-aliyun 以降のバージョンの新しいデプロイメントでのみデフォルトで有効になります。
解決策
Headless Service を使用してサービスを公開し、アクセスします。詳細については、「Headless Services」をご参照ください。
説明これは推奨される方法です。
クラスターを再作成し、Terway ネットワークプラグインを使用します。詳細については、「Terway ネットワークプラグインを使用する」をご参照ください。
Flannel 構成を変更し、Flannel プラグインと Pod を再作成します。
説明この方法は、構成が後続のアップグレードによって上書きされる可能性があるため、推奨されません。
cni-config.json を編集します。
kubectl edit cm kube-flannel-cfg -n kube-system構成で、
delegateセクションに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=flannelPod を削除して再作成します。
Kubernetes クラスター用の Terway と Flannel ネットワークプラグインのどちらを選択すればよいですか？
このセクションでは、ACK クラスターを作成する際に利用可能な 2 つのネットワークプラグイン、Terway と Flannel について説明します。
Kubernetes クラスターを作成する際、ACK は 2 つのネットワークプラグインを提供します。
Flannel: このプラグインは、オープンソースコミュニティのシンプルで安定した Flannel CNI プラグインを使用します。高速な Alibaba Cloud VPC ネットワークと連携して、コンテナーに高性能で安定したネットワークを提供します。ただし、基本的な機能のみを提供し、標準の Kubernetes ネットワークポリシーなどの高度な機能は備えていません。
Terway: これは ACK が開発したネットワークプラグインです。Flannel と完全に互換性があり、Alibaba Cloud ENI をコンテナーに割り当てることをサポートしています。また、標準の Kubernetes ネットワークポリシーをサポートしてコンテナー間のアクセスポリシーを定義し、個々のコンテナーの帯域幅を制限することもできます。ネットワークポリシーを使用する必要がない場合は、Flannel を選択できます。それ以外の場合は、Terway を使用することをお勧めします。Terway ネットワークプラグインの詳細については、「Terway ネットワークプラグインを使用する」をご参照ください。
クラスターネットワークを計画する方法
ACK クラスターを作成する際には、VPC、vSwitch、Pod ネットワーク CIDR ブロック、および Service CIDR ブロックを指定する必要があります。ECS インスタンスアドレス、Kubernetes Pod アドレス、およびサービスアドレスを事前に計画することをお勧めします。詳細については、「ACK マネージドクラスターのネットワークを計画する」をご参照ください。
ACK は hostPort マッピングをサポートしていますか？
Flannel プラグインのみが hostPort をサポートしています。他のプラグインはこの機能をサポートしていません。
ACK の Pod アドレスは、追加のポートマッピングを必要とせずに、同じ VPC 内の他のリソースから直接アクセスできます。
サービスを外部ネットワークに公開するには、NodePort または LoadBalancer タイプのサービスを使用します。
クラスターのネットワークタイプとそれに対応する vSwitch を表示する方法
ACK は、Flannel と Terway の 2 つのコンテナーネットワークタイプをサポートしています。
クラスター作成時に選択したネットワークタイプを表示するには、次の手順を実行します。
ACK コンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
クラスター ページで、目的のクラスターを見つけてその名前をクリックします。左側のナビゲーションウィンドウで、クラスター情報 をクリックします。
[基本情報] タブをクリックします。[ネットワーク] セクションで、クラスターのコンテナーネットワークタイプを表示します。これは [ネットワークプラグイン] の横の値です。
[ネットワークプラグイン] が [Terway] に設定されている場合、コンテナーネットワークタイプは Terway です。
[ネットワークプラグイン] が [Flannel] に設定されている場合、コンテナーネットワークタイプは Flannel です。
ネットワークタイプで使用されるノード vSwitch を表示するには、次の手順を実行します。
左側のナビゲーションウィンドウで、 を選択します。
[ノードプール] ページで、目的のノードプールを見つけ、[アクション] 列の [詳細] をクリックします。次に、[基本情報] タブをクリックします。
[ノード構成] セクションで、[ノード VSwitch] ID を表示します。
Terway ネットワークタイプで使用される Pod vSwitch ID をクエリするには、次の手順を実行します。
説明Terway ネットワークタイプのみが Pod vSwitch を使用します。Flannel ネットワークタイプは使用しません。
左側のナビゲーションウィンドウで、[アドオン] をクリックします。
[アドオン] ページで、terway-eniip カードの [構成の表示] をクリックします。PodVswitchId オプションには、現在使用中の Pod vSwitch が表示されます。
クラスターで使用されているクラウドリソースを表示する方法
仮想マシン、VPC、ワーカー RAM ロールなど、クラスターで使用されているクラウドリソースに関する情報を表示するには、次の手順を実行します。
ACK コンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
[クラスター] ページで、目的のクラスターの名前をクリックするか、クラスターの [アクション] 列の [詳細] をクリックします。
[基本情報] タブをクリックして、クラスターで使用されているクラウドリソースに関する情報を表示します。
kube-proxy の構成を変更する方法
デフォルトでは、ACK マネージドクラスターはロードバランシングのために kube-proxy-worker DaemonSet をデプロイします。そのパラメーターは kube-proxy-worker ConfigMap を使用して制御できます。ACK 専用クラスターを使用する場合、kube-proxy-master DaemonSet と対応する ConfigMap もクラスターにデプロイされ、マスターノードで実行されます。
kube-proxy 構成は、コミュニティの KubeProxyConfiguration 標準と互換性があります。この標準に基づいて構成をカスタマイズできます。詳細については、「kube-proxy 構成」をご参照ください。kube-proxy 構成ファイルには厳密なフォーマット要件があります。コロンやスペースを省略しないでください。kube-proxy 構成を変更するには、次の手順を実行します。
マネージドクラスターを使用する場合、kube-proxy-worker の構成を変更する必要があります。
ACK コンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
クラスター ページで、目的のクラスターを見つけてその名前をクリックします。左側のペインで、 を選択します。
ページの上部で、[kube-system] 名前空間を選択します。次に、kube-proxy-worker ConfigMap を見つけ、[アクション] 列の [YAML の編集] をクリックします。
[YAML の編集] パネルで、パラメーターを変更し、[OK] をクリックします。
構成を有効にするには、すべての kube-proxy-worker コンテナーを再作成します。
重要kube-proxy を再起動しても、実行中のサービスは中断されません。サービスが同時にリリースされている場合、新しいサービスが kube-proxy で有効になるまでに少し時間がかかることがあります。この操作はオフピーク時に実行することをお勧めします。
クラスター管理ページの左側のナビゲーションウィンドウで、 を選択します。
DaemonSet のリストで、kube-proxy-worker を見つけてクリックします。
kube-proxy-worker ページの [Pod] タブで、 を選択し、[OK] をクリックします。
この操作を繰り返してすべての Pod を削除します。Pod は削除された後、システムによって自動的に再作成されます。
専用クラスターを使用する場合、kube-proxy-worker と kube-proxy-master の両方の構成を変更する必要があります。次に、kube-proxy-worker と kube-proxy-master の Pod を削除します。Pod は自動的に再作成され、新しい構成が有効になります。詳細については、上記の手順をご参照ください。
Linux 接続追跡 (conntrack) の制限を増やす方法
カーネルログ (dmesg) に conntrack full エラーメッセージが含まれている場合、conntrack エントリの数が conntrack_max 制限に達しています。Linux conntrack の制限を増やす必要があります。
次のコマンドを実行して、現在の conntrack の使用状況と各プロトコルのカウントを確認します。
# テーブルの詳細を表示します。grep パイプラインを使用してステータスを確認するか、cat /proc/net/nf_conntrack を使用できます。 conntrack -L # カウントを表示します。 cat /proc/sys/net/netfilter/nf_conntrack_count # テーブルの現在の最大値を表示します。 cat /proc/sys/net/netfilter/nf_conntrack_max多くの TCP プロトコルエントリが存在する場合、特定のサービスを確認してください。短命な接続アプリケーションの場合は、持続的接続アプリケーションに変更することを検討してください。
多くの DNS エントリが存在する場合、ACK クラスターで NodeLocal DNSCache を使用して DNS パフォーマンスを向上させます。詳細については、「NodeLocal DNSCache コンポーネントを使用する」をご参照ください。
多くのアプリケーション層のタイムアウトや 504 エラーが発生する場合、またはオペレーティングシステムのカーネルログに
kernel: nf_conntrack: table full, dropping packet.エラーが出力される場合は、conntrack 関連のパラメーターを慎重に調整してください。
実際の conntrack 使用量が妥当である場合、またはサービスを変更したくない場合は、kube-proxy 構成に maxPerCore パラメーターを追加することで、接続追跡の制限を調整できます。
マネージドクラスターを使用する場合、kube-proxy-worker 構成に maxPerCore パラメーターを追加し、その値を 65536 以上に設定する必要があります。次に、kube-proxy-worker Pod を削除します。Pod は自動的に再作成され、新しい構成が有効になります。kube-proxy-worker の変更および削除方法の詳細については、「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 # maxPerCore を適切な値に設定します。65536 はデフォルト設定です。 mode: ipvs # 他のフィールドは省略されています。専用クラスターを使用する場合、kube-proxy-worker と kube-proxy-master の構成に maxPerCore パラメーターを追加し、その値を 65536 以上に設定する必要があります。次に、kube-proxy-worker と kube-proxy-master の Pod を削除します。Pod は自動的に再作成され、新しい構成が有効になります。kube-proxy-worker と kube-proxy-master の変更および削除方法の詳細については、「kube-proxy の構成を変更する方法」をご参照ください。
Terway DataPath V2 または IPvlan モードでは、コンテナートラフィックの conntrack 情報は eBPF マップに保存されます。他のモードでは、conntrack 情報は Linux conntrack に保存されます。eBPF conntrack サイズの調整方法の詳細については、「Terway モードでの conntrack 構成の最適化」をご参照ください。
kube-proxy の IPVS ロードバランシングモードを変更する方法
サービスが持続的接続を使用している場合、各接続が複数のリクエストを送信するため、バックエンド Pod へのリクエスト数が不均等になることがあります。この不均等な負荷の問題は、kube-proxy の IPVS ロードバランシングモードを変更することで解決できます。次の手順を実行します。
適切なスケジューリングアルゴリズムを選択します。適切なスケジューリングアルゴリズムの選択方法の詳細については、Kubernetes ドキュメントの「parameter-changes」をご参照ください。
2022 年 10 月より前に作成されたクラスターノードでは、すべての IPVS スケジューリングアルゴリズムがデフォルトで有効になっていない場合があります。すべてのクラスターノードで IPVS スケジューリングアルゴリズムのカーネルモジュールを手動で有効にする必要があります。たとえば、最小接続 (lc) スケジューリングアルゴリズムを使用するには、各ノードにログインし、lsmod | grep ip_vs_lc を実行して出力があるかどうかを確認します。別のアルゴリズムを選択した場合は、`lc` を対応するキーワードに置き換えます。
コマンドが ip_vs_lc を出力した場合、スケジューリングアルゴリズムのカーネルモジュールはすでにロードされているため、このステップはスキップできます。
ロードされていない場合は、modprobe ip_vs_lc を実行してノードで即座に有効にします。次に、echo "ip_vs_lc" >> /etc/modules-load.d/ack-ipvs-modules.conf を実行して、ノードの再起動後も変更が持続するようにします。
kube-proxy の ipvs.scheduler パラメーターを適切なスケジューリングアルゴリズムに設定します。
マネージドクラスターを使用する場合、kube-proxy-worker の ipvs.scheduler パラメーターを適切なスケジューリングアルゴリズムに設定する必要があります。次に、kube-proxy-worker Pod を削除します。Pod は自動的に再作成され、新しい構成が有効になります。kube-proxy-worker の変更および削除方法の詳細については、「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 # scheduler を適切なスケジューリングアルゴリズムに設定します。 # 他のフィールドは省略されています。専用クラスターを使用する場合、kube-proxy-worker と kube-proxy-master の ipvs.scheduler パラメーターを適切なスケジューリングアルゴリズムに設定する必要があります。次に、kube-proxy-worker と kube-proxy-master の Pod を削除します。Pod は自動的に再作成され、新しい構成が有効になります。kube-proxy-worker と kube-proxy-master の変更および削除方法の詳細については、「kube-proxy の構成を変更する方法」をご参照ください。
kube-proxy の実行ログを確認します。
kubectl get pods コマンドを実行して、kube-system 名前空間の新しい kube-proxy-worker コンテナーが Running 状態にあるかどうかを確認します。専用クラスターを使用する場合は、kube-proxy-master も確認します。
kubectl logs コマンドを実行して、新しいコンテナーのログを表示します。
ログに Can't use the IPVS proxier: IPVS proxier will not be used because the following required kernel modules are not loaded: [ip_vs_lc] が含まれている場合、IPVS スケジューリングアルゴリズムのカーネルモジュールのロードに失敗しました。前の手順が正しく実行されたことを確認し、再試行してください。
ログに Using iptables Proxier. が含まれている場合、kube-proxy は IPVS モジュールの有効化に失敗し、自動的に iptables モードにフォールバックしました。この場合、まず kube-proxy 構成をロールバックしてからノードを再起動することをお勧めします。
上記のログエントリが表示されず、ログに Using ipvs Proxier. が表示される場合、IPVS モジュールは正常に有効化されました。
上記のすべてのチェックに合格した場合、変更は成功です。
kube-proxy の IPVS UDP セッション維持タイムアウトを変更する方法
ACK クラスターが IPVS モードで kube-proxy を使用している場合、デフォルトの IPVS セッション維持ポリシーにより、UDP バックエンドが削除された後、最大 5 分間、確率的にパケット損失が発生する可能性があります。サービスが CoreDNS に依存している場合、CoreDNS コンポーネントがアップグレードされたり、そのノードが再起動されたりすると、最大 5 分間、ビジネスインターフェイスの遅延、リクエストのタイムアウト、その他の問題が発生する可能性があります。
ACK クラスター内のサービスが UDP プロトコルを使用していない場合、IPVS UDP プロトコルのセッション維持タイムアウトを短くすることで、解析遅延や失敗の影響を軽減できます。次の手順を実行します。
独自のサービスが UDP プロトコルを使用している場合は、チケットを送信してご相談ください。
K8s 1.18 以降のクラスターの場合
マネージドクラスターを使用する場合、kube-proxy-worker の udpTimeout パラメーター値を変更する必要があります。次に、kube-proxy-worker Pod を削除します。Pod は自動的に再作成され、新しい構成が有効になります。kube-proxy-worker の変更および削除方法の詳細については、「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 # 他の無関係なフィールドは省略されています。 mode: ipvs # ipvs キーが存在しない場合は、追加する必要があります。 ipvs: udpTimeout: 10s # デフォルトは 300 秒です。10 秒に変更すると、IPVS UDP バックエンドが削除された後のパケット損失の影響時間を 10 秒に短縮できます。専用クラスターを使用する場合、kube-proxy-worker と kube-proxy-master の udpTimeout パラメーター値を変更する必要があります。次に、kube-proxy-worker と kube-proxy-master の Pod を削除します。Pod は自動的に再作成され、新しい構成が有効になります。kube-proxy-worker の変更方法の詳細については、「kube-proxy の構成を変更する方法」をご参照ください。
K8s 1.16 以前のクラスターの場合
このバージョンのクラスターの kube-proxy コンポーネントは、udpTimeout パラメーターをサポートしていません。UDP タイムアウト構成を調整するには、CloudOps Orchestration Service (OOS) を使用して、クラスター内のすべてのノードで次の
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 でのバッチ操作の詳細については、「バッチ操作インスタンス」をご参照ください。
IPv6 デュアルスタックの一般的な問題を解決する方法
症状: kubectl に表示される Pod IP アドレスがまだ IPv4 アドレスです。
解決策: 次のコマンドを実行して Pod IPs フィールドを表示します。期待される出力は IPv6 アドレスです。
kubectl get pods -A -o jsonpath='{range .items[*]}{@.metadata.namespace} {@.metadata.name} {@.status.podIPs[*].ip} {"\n"}{end}'症状: kubectl に表示されるクラスター IP がまだ IPv4 アドレスです。
解決策:
spec.ipFamilyPolicy が SingleStack に設定されていないことを確認してください。
次のコマンドを実行して Cluster IPs フィールドを表示します。期待される出力は IPv6 アドレスです。
kubectl get svc -A -o jsonpath='{range .items[*]}{@.metadata.namespace} {@.metadata.name} {@.spec.ipFamilyPolicy} {@.spec.clusterIPs[*]} {"\n"}{end}'
症状: IPv6 アドレスを使用して Pod にアクセスできません。
原因: Nginx コンテナーなどの一部のアプリケーションは、デフォルトで IPv6 アドレスをリッスンしません。
解決策:
netstat -anpコマンドを実行して、Pod が 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 アドレスをリッスンしていることを意味します。症状: クラスター内で Pod に IPv6 アドレスでアクセスできますが、インターネットからはアクセスできません。
原因: IPv6 アドレスにインターネット帯域幅が設定されていない可能性があります。
解決策: IPv6 アドレスにインターネット帯域幅を設定します。詳細については、「IPv6 パブリック帯域幅を有効にして管理する」をご参照ください。
症状: IPv6 クラスター IP を使用して Pod にアクセスできません。
解決策:
spec.ipFamilyPolicy が SingleStack に設定されていないことを確認してください。
netstat -anpコマンドを実行して、Pod が 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 アドレスをリッスンしていることを意味します。症状: Pod が IPv6 を使用してインターネットにアクセスできません。
解決策: IPv6 を使用してインターネットにアクセスするには、IPv6 ゲートウェイを有効にし、IPv6 アドレスにインターネット帯域幅を設定する必要があります。詳細については、「IPv6 ゲートウェイを作成および管理する」および「IPv6 パブリック帯域幅を有効にして管理する」をご参照ください。
Terway ネットワークモードで vSwitch の IP リソースが不足した場合はどうすればよいですか？
説明
Pod を作成しようとすると、作成が失敗します。VPC コンソールにログインし、目的のリージョンを選択して、クラスターで使用されている vSwitch の情報を表示します。vSwitch の利用可能な IP アドレス数が 0 であることがわかります。問題の確認方法の詳細については、「詳細情報」をご参照ください。
原因
ノード上の Terway が使用する vSwitch に利用可能な IP アドレスがありません。これにより、IP リソースの不足により Pod が ContainerCreating 状態のままになります。
解決策
新しい vSwitch を追加して vSwitch をスケールアウトし、クラスターの IP リソースを増やすことができます。
VPC コンソールにログインし、目的のリージョンを選択して、新しい vSwitch を作成します。
説明新しい vSwitch は、IP リソースが不足している vSwitch と同じリージョンおよびゾーンにある必要があります。Pod の密度が増加している場合は、Pod の vSwitch CIDR ブロックのネットワークプレフィックスを /19 以下にすることをお勧めします。これは、CIDR ブロックに少なくとも 8,192 個の IP アドレスが含まれることを意味します。
ACK コンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。[クラスター] ページで、目的のクラスターの名前をクリックし、左側のナビゲーションウィンドウで [アドオン] をクリックします。
[アドオン] ページで、terway-eniip カードを見つけ、[構成の表示] をクリックし、前のステップで作成した vSwitch の ID を PodVswitchId オプションに追加します。
次のコマンドを実行して、すべての Terway Pod を削除します。Terway Pod は削除された後、自動的に再作成されます。
説明Terway でクラスターを作成する際に最高のパフォーマンスを実現するために Pod に排他的な ENI を選択した場合、ENI シングル IP モードを使用しています。このオプションを選択しなかった場合、ENI マルチ IP モードを使用しています。詳細については、「Terway ネットワークプラグイン」をご参照ください。
ENI マルチ IP シナリオの場合:
kubectl delete -n kube-system pod -l app=terway-eniipENI シングル IP シナリオの場合:
kubectl delete -n kube-system pod -l app=terway-eni
次に、
kubectl get podコマンドを実行して、すべての Terway Pod が正常に再作成されたことを確認します。新しい Pod を作成し、正常に作成され、新しい vSwitch から IP アドレスが割り当てられていることを確認します。
詳細情報
Kubernetes クラスターに接続します。接続方法の詳細については、「kubectl を使用して Kubernetes クラスターに接続する」をご参照ください。kubectl get pod コマンドを実行すると、Pod のステータスが ContainerCreating であることがわかります。次のコマンドを実行して、Pod が配置されているノード上の Terway コンテナーのログを表示します。
kubectl get pod -l app=terway-eniip -n kube-system | grep [$Node_Name] # [$Node_Name] は Pod が配置されているノードの名前です。これを使用して、そのノード上の Terway Pod の名前を見つけます。
kubectl logs --tail=100 -f [$Pod_Name] -n kube-system -c terway # [$Pod_Name] は Pod が配置されているノード上の Terway Pod の名前です。システムは次のようなメッセージを表示し、`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"Terway ネットワークモードの Pod に vSwitch CIDR ブロックにない IP アドレスが割り当てられた場合はどうすればよいですか？
症状
Terway ネットワークで、作成された Pod に、構成された vSwitch CIDR ブロック内にない IP アドレスが割り当てられます。
原因
Pod IP アドレスは VPC から供給され、ENI を使用してコンテナーに割り当てられます。vSwitch は新しい ENI を作成するときにのみ構成できます。ENI がすでに存在する場合、Pod IP アドレスは引き続きその ENI に対応する vSwitch から割り当てられます。
この問題は通常、次の 2 つのシナリオで発生します。
クラスターにノードを追加しますが、このノードは以前に別のクラスターで使用されており、ノードが削除されたときに Pod がドレインされていませんでした。この場合、前のクラスターの ENI リソースがノードに残っている可能性があります。
Terway が使用する vSwitch 構成を手動で追加または変更します。元の構成を持つ ENI がノードにまだ存在する可能性があるため、新しい Pod は引き続き元の ENI の IP アドレスを使用する可能性があります。
解決策
新しいノードを作成し、古いノードをローテーションすることで、構成ファイルが有効になるようにできます。
古いノードをローテーションするには、次の手順を実行します。
古いノードをドレインして削除します。詳細については、「ノードを削除する」をご参照ください。
削除されたノードから ENI をデタッチします。詳細については、「ENI を管理する」をご参照ください。
ENI がデタッチされた後、削除されたノードを元の ACK クラスターに再度追加します。詳細については、「既存のノードを追加する」をご参照ください。
Terway ネットワークモードで vSwitch をスケールアウトした後も Pod に IP アドレスを割り当てることができない場合はどうすればよいですか？
症状
Terway ネットワークでは、vSwitch をスケールアウトした後も Pod に IP アドレスを割り当てることができません。
原因
Pod IP アドレスは VPC から供給され、ENI を使用してコンテナーに割り当てられます。vSwitch は新しい ENI を作成するときにのみ構成できます。ENI がすでに存在する場合、Pod IP アドレスは引き続きその ENI に対応する vSwitch から割り当てられます。ノードの ENI クォータが使い果たされているため、新しい ENI を作成できず、したがって新しい構成を有効にできません。ENI クォータの詳細については、「ENI の概要」をご参照ください。
解決策
新しいノードを作成し、古いノードをローテーションすることで、構成ファイルが有効になるようにできます。
古いノードをローテーションするには、次の手順を実行します。
古いノードをドレインして削除します。詳細については、「ノードを削除する」をご参照ください。
削除されたノードから ENI をデタッチします。詳細については、「ENI を管理する」をご参照ください。
ENI がデタッチされた後、削除されたノードを元の ACK クラスターに再度追加します。詳細については、「既存のノードを追加する」をご参照ください。
Terway IPvlan クラスターのクラスター内ロードバランシングを有効にする方法
症状
IPvlan モードでは、Terway v1.2.0 以降の場合、新しいクラスターではクラスター内ロードバランシングがデフォルトで有効になっています。クラスター内から ExternalIP または LoadBalancer にアクセスすると、トラフィックはサービスネットワークにロードバランシングされます。既存の Terway IPvlan クラスターでクラスター内ロードバランシングを有効にするにはどうすればよいですか？
原因
Kube-proxy は、クラスター内からの ExternalIP および LoadBalancer へのトラフィックをショートサーキットします。これは、クラスター内からこれらの外部アドレスにアクセスすると、トラフィックは実際には外部に出ず、代わりに対応するバックエンドのエンドポイントに直接リダイレクトされることを意味します。Terway IPvlan モードでは、これらのアドレスへのトラフィックは kube-proxy ではなく Cilium によって処理されます。v1.2.0 より前の Terway バージョンでは、このショートサーキットはサポートされていませんでした。Terway v1.2.0 のリリース後、この機能は新しいクラスターではデフォルトで有効になりますが、既存のクラスターでは有効になりません。
解決策
Terway は v1.2.0 以降で、IPvlan モードを使用している必要があります。
クラスターが IPvlan モードを有効にしていない場合、この構成は無効であり、構成する必要はありません。
この機能は新しいクラスターではデフォルトで有効になっており、構成する必要はありません。
次のコマンドを実行して Terway ConfigMap を変更します。
kubectl edit cm eni-config -n kube-systemeni_conf に次の内容を追加します。
in_cluster_loadbalance: "true"説明in_cluster_loadbalanceとeni_confが同じレベルにあることを確認してください。次のコマンドを実行して Terway Pod を再作成し、クラスター内ロードバランシング構成を有効にします。
kubectl delete pod -n kube-system -l app=terway-eniip構成の確認
次のコマンドを実行して terway-ennip policy ログを確認します。
enable-in-cluster-loadbalance=trueと表示されていれば、構成は有効になっています。kubectl logs -n kube-system <terway pod name> policy | grep enable-in-cluster-loadbalance
Terway を使用する ACK クラスターの Pod のホワイトリストに特定の CIDR ブロックを追加する方法
症状
データベースなどのサービスに対して、より安全なアクセスの制御を提供するために、ホワイトリストを設定する必要がよくあります。この要件はコンテナーネットワークにも存在し、動的に変化する Pod IP アドレスに対してホワイトリストを設定する必要があります。
原因
ACK のコンテナーネットワークは、主に Flannel と Terway の 2 つのプラグインを使用します。
Flannel ネットワークでは、Pod はノードを介して他のサービスにアクセスするため、ノードアフィニティを使用してクライアント Pod を小規模で固定されたノードセットにスケジュールできます。その後、これらのノードの IP アドレスをデータベースのホワイトリストに追加できます。
Terway ネットワークでは、Pod IP アドレスは ENI によって提供されます。Pod が ENI を介して外部サービスにアクセスすると、外部サービスはクライアント IP を ENI によって提供された IP アドレスとして認識し、ノードの IP ではありません。Pod をアフィニティでノードにバインドしても、外部アクセス用のクライアント IP は依然として ENI の IP です。Pod IP アドレスは、Terway によって指定された vSwitch からランダムに割り当てられます。さらに、クライアント Pod は多くの場合、自動スケーリングなどの構成を持っているため、Pod IP を固定できたとしても、弾力的なスケーリングのニーズを満たすことは困難です。クライアントが IP アドレスを割り当てるための特定の CIDR ブロックを割り当て、その CIDR ブロックをデータベースのホワイトリストに追加することをお勧めします。
解決策
特定のノードにラベルを追加することで、Pod が使用する vSwitch を指定できます。Pod が固定ラベルを持つノードにスケジュールされると、カスタム vSwitch を使用して Pod IP を作成できます。
kube-system 名前空間に、専用の vSwitch を指定する eni-config-fixed という名前の別の ConfigMap を作成します。
この例では、vsw-2zem796p76viir02c**** と 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ラベルを追加します。ノードプールの作成方法の詳細については、「ノードプールを作成する」をご参照ください。他の Pod がこのノードプールのノードにスケジュールされないようにするために、
fixed=true:NoScheduleなどの Taint をノードプールに構成することもできます。
ノードプールをスケールアウトします。詳細については、「ノードプールを手動でスケーリングする」をご参照ください。
このノードプールからスケールアウトされたノードには、前のステップで設定したノードラベルと Taint がデフォルトで設定されます。
Pod を作成し、
terway-config:eni-config-fixedラベルを持つノードにスケジュールします。Toleration を追加する必要があります。apiVersion: apps/v1 # 1.8.0 より前のバージョンの場合は、apps/v1beta1 を使用します。 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: # Toleration を追加します。 - key: "fixed" operator: "Equal" value: "true" effect: "NoSchedule" nodeSelector: terway-config: eni-config-fixed containers: - name: nginx image: nginx:1.9.0 # 実際のイメージ <image_name:tags> に置き換えます。 ports: - containerPort: 80結果の確認
次のコマンドを実行して Pod 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>Pod IP アドレスが指定された vSwitch から割り当てられていることがわかります。
次のコマンドを実行して、Pod を 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> ...生成されたすべての Pod IP アドレスが指定された vSwitch 内にあることがわかります。次に、この vSwitch をデータベースのホワイトリストに追加して、動的な Pod IP アドレスのアクセスを制御できます。
新しく作成されたノードを使用することをお勧めします。既存のノードを使用する場合は、ノードをクラスターに追加する前に ECS インスタンスから ENI をデタッチする必要があります。既存のノードを追加するには、自動的な方法 (システムディスクを置き換える) を使用する必要があります。詳細については、「ENI を管理する」および「既存のノードを自動的に追加する」をご参照ください。
ホワイトリストに登録する必要のないサービスがこれらのノードにスケジュールされないように、特定のノードプールにラベルと Taint を追加してください。
このホワイトリスト登録方法は、本質的に構成のオーバーライドです。ACK は、指定された ConfigMap の構成を使用して、以前の eni-config をオーバーライドします。構成パラメーターの詳細については、「Terway ノード動的構成」をご参照ください。
指定された vSwitch の IP アドレスの数は、予想される Pod の数の少なくとも 2 倍にすることをお勧めします。これにより、将来のスケーリングのためのバッファーが提供され、IP アドレスのタイムリーな回収を妨げる障害により割り当て可能な IP アドレスがなくなる状況を防ぐのに役立ちます。
Pod が一部の ECS ノードに ping できないのはなぜですか？
症状
Flannel ネットワークモードで、VPN ルートが正常であることを確認しますが、Pod に入ると、一部の ECS ノードに ping できないことがわかります。
原因
Pod が一部の ECS ノードに ping できない理由は 2 つあります。
原因 1: Pod がアクセスしている ECS インスタンスはクラスターと同じ VPC にありますが、同じセキュリティグループにはありません。
原因 2: Pod がアクセスしている ECS インスタンスはクラスターと同じ VPC にありません。
解決策
解決策は原因によって異なります。
原因 1 の場合、ECS インスタンスをクラスターのセキュリティグループに追加する必要があります。詳細については、「セキュリティグループを構成する」をご参照ください。
原因 2 の場合、ECS インスタンスにパブリックエンドポイントを介してアクセスする必要があります。クラスターのパブリック出口 IP アドレスを ECS インスタンスのセキュリティグループに追加する必要があります。
クラスターノードに NodeNetworkUnavailable Taint があるのはなぜですか？
症状
Flannel ネットワークモードで、新しく追加されたクラスターノードに NodeNetworkUnavailable Taint があり、Pod のスケジュールが妨げられます。
原因
Cloud Controller Manager (CCM) がノードの Taint を迅速に削除しなかったため、ルートテーブルがいっぱいであるか、VPC に複数のルートテーブルが存在する可能性があります。
解決策
kubectl describe node コマンドを使用してノードのイベント情報を表示し、実際の出力に基づいてエラーを処理します。複数のルートテーブルの問題については、CCM を手動で構成してサポートする必要があります。詳細については、「VPC で複数のルートテーブルを使用する」をご参照ください。
Pod の起動に失敗し、「範囲内に利用可能な IP アドレスがありません」というエラーが報告されるのはなぜですか？
症状
Flannel ネットワークモードで、Pod の起動に失敗します。Pod イベントを確認すると、failed to allocate for range 0: no IP addresses available in range set: 172.30.34.129-172.30.34.190 のようなエラーメッセージが表示されます。
原因
解決策
古い ACK バージョンによる IP アドレスのリークについては、クラスターをバージョン 1.20 以降にアップグレードできます。詳細については、「クラスターを手動でアップグレードする」をご参照ください。
古い Flannel バージョンによる IP アドレスのリークについては、Flannel を v0.15.1.11-7e95fe23-aliyun 以降にアップグレードできます。次の手順を実行します。
Flannel v0.15.1.11-7e95fe23-aliyun 以降では、ACK は Flannel のデフォルトの IP 範囲割り当てデータベースを一時ディレクトリ /var/run に移行します。このディレクトリは再起動時に自動的にクリアされ、IP アドレスのリークを防ぎます。
Flannel を 0.15.1.11-7e95fe23-aliyun 以降に更新します。詳細については、「コンポーネントを管理する」をご参照ください。
次のコマンドを実行して kube-flannel-cfg ファイルを編集します。次に、dataDir および ipam パラメーターを kube-flannel-cfg ファイルに追加します。
kubectl -n kube-system edit cm kube-flannel-cfgkube-flannel-cfg ファイルの例を次に示します。
# 変更前 { "name": "cb0", "cniVersion":"0.3.1", "plugins": [ { "type": "flannel", "delegate": { "isDefaultGateway": true, "hairpinMode": true } }, # portmap # 古いバージョンには存在しない場合があります。使用しない場合は無視してください。 { "type": "portmap", "capabilities": { "portMappings": true }, "externalSetMarkChain": "KUBE-MARK-MASQ" } ] } # 変更後 { "name": "cb0", "cniVersion":"0.3.1", "plugins": [ { "type": "flannel", "delegate": { "isDefaultGateway": true, "hairpinMode": true }, # カンマに注意してください。 "dataDir": "/var/run/cni/flannel", "ipam": { "type": "host-local", "dataDir": "/var/run/cni/networks" } }, { "type": "portmap", "capabilities": { "portMappings": true }, "externalSetMarkChain": "KUBE-MARK-MASQ" } ] }次のコマンドを実行して Flannel Pod を再起動します。
Flannel Pod を再起動しても、実行中のサービスには影響しません。
kubectl -n kube-system delete pod -l app=flannelノード上の IP ディレクトリを削除し、ノードを再起動します。
ノード上の既存の Pod をドレインします。詳細については、「ノードをドレインしてそのスケジューリングステータスを管理する」をご参照ください。
ノードにログインし、次のコマンドを実行して IP ディレクトリを削除します。
rm -rf /etc/cni/ rm -rf /var/lib/cni/ノードを再起動します。詳細については、「インスタンスを再起動する」をご参照ください。
上記の手順を繰り返して、すべてのノードの IP ディレクトリを削除します。
ノードで次のコマンドを実行して、一時ディレクトリが有効になっているかどうかを確認します。
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が返された場合、現在のノードが IP 範囲割り当てデータベースに一時ディレクトリ /var/run を有効にしており、変更が成功したことを示します。
短期間で ACK または Flannel をアップグレードできない場合は、一時的な緊急対応として次の方法を使用できます。この一時的な修正は、上記の両方の理由によるリークに適用できます。
この一時的な修正は、リークした IP アドレスをクリーンアップするのに役立つだけです。IP アドレスのリークは依然として発生する可能性があるため、Flannel またはクラスターのバージョンをアップグレードする必要があります。
説明次のコマンドは、IP アドレス割り当て情報を格納するために /var/run を使用するようにすでに切り替わっている Flannel v0.15.1.11-7e95fe23-aliyun 以降のバージョンには適用されません。
次のスクリプトは参照用です。ノードがカスタマイズされている場合、スクリプトは正しく機能しない可能性があります。
問題のあるノードをスケジュール不可の状態に設定します。詳細については、「ノードをドレインしてそのスケジューリングステータスを管理する」をご参照ください。
ランタイムエンジンに基づいて、次のスクリプトを使用してノードをクリーンアップします。
Docker ランタイムを使用している場合は、次のスクリプトを使用してノードをクリーンアップします。
#!/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) donecontainerd ランタイムを使用している場合は、次のスクリプトを使用してノードをクリーンアップします。
#!/bin/bash # jq をインストールします yum install -y jq # 実行中のすべての Pod の設定をエクスポートします 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 # 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 # flannel の割り当て済みのすべての Pod IP をエクスポートします ls -alh /var/lib/cni/networks/cb0/1* | cut -f7 -d"/" | sort > /tmp/flannel_ip_gc_all_allocated_pod_ips # リークした 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 # リークした Pod IP をクリーンアップします echo "Found $(cat /tmp/flannel_ip_gc_leaked_pod_ip | wc -l) leaked Pod IP, press <Enter> to clean." read sure # リークした 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
問題のあるノードをスケジュール可能な状態に設定します。詳細については、「ノードをドレインしてそのスケジューリングステータスを管理する」をご参照ください。
ノード IP の数、Pod IP CIDR ブロック、または Service IP CIDR ブロックを変更する方法
ノード IP の数、Pod IP CIDR ブロック、および Service IP CIDR ブロックは、クラスターの作成後に変更することはできません。クラスターを作成する際に、ネットワークセグメントを合理的に計画してください。
どのようなシナリオでクラスターに複数のルートテーブルを設定する必要がありますか？
Flannel ネットワークモードでは、cloud-controller-manager に複数のルートテーブルを設定する必要がある一般的なシナリオは次のとおりです。クラスターに複数のルートテーブルを設定する方法の詳細については、「VPC で複数のルートテーブルを使用する」をご参照ください。
シナリオ
シナリオ 1:
システム診断で「ノードの Pod CIDR ブロックが VPC ルートテーブルエントリにありません。カスタムルートテーブルにカスタムルートエントリを追加して、Pod CIDR ブロックのネクストホップルートを現在のノードに追加してください。」というプロンプトが表示されます。
原因: クラスターにカスタムルートテーブルを作成する場合、複数のルートテーブルをサポートするように CCM を構成する必要があります。
シナリオ 2:
cloud-controller-manager コンポーネントがネットワークエラーを報告します:
multiple route tables found。原因: クラスターに複数のルートテーブルが存在する場合、複数のルートテーブルをサポートするように CCM を構成する必要があります。
シナリオ 3:
Flannel ネットワークモードでは、新しく追加されたクラスターノードに NodeNetworkUnavailable Taint があり、cloud-controller-manager コンポーネントがノードの Taint を迅速に削除しないため、Pod のスケジュールが妨げられます。詳細については、「クラスターノードに NodeNetworkUnavailable Taint があるのはなぜですか？」をご参照ください。
サードパーティのネットワークプラグインはサポートされていますか？
ACK クラスターは、サードパーティのネットワークプラグインのインストールと構成をサポートしていません。インストールすると、クラスターネットワークが利用できなくなる可能性があります。
Pod CIDR アドレスが不足し、no IP addresses available in range set エラーが発生するのはなぜですか？
このエラーは、ACK クラスターが Flannel ネットワークプラグインを使用しているために発生します。Flannel は Pod ネットワーク CIDR ブロックを定義し、各ノードに Pod に割り当てるための限られた IP アドレスセットを提供します。この範囲は変更できません。範囲内の IP アドレスが使い果たされると、ノード上に新しい Pod を作成できなくなります。一部の IP アドレスを解放するか、クラスターを再作成する必要があります。クラスターネットワークの計画方法の詳細については、「ACK マネージドクラスターのネットワークを計画する」をご参照ください。
Terway ネットワークモードでサポートされる Pod の数はいくつですか？
Terway ネットワークモードでクラスターがサポートする Pod の数は、ECS インスタンスがサポートする IP アドレスの数です。詳細については、「Terway ネットワークプラグインを使用する」をご参照ください。
Terway DataPath V2 データプレーンモード
Terway v1.8.0 以降、新しいクラスターを作成して IPvlan オプションを選択すると、DataPath V2 モードがデフォルトで有効になります。すでに IPvlan 機能を有効にしている既存のクラスターでは、データプレーンは元の IPvlan メソッドのままです。
DataPath V2 は新世代のデータプレーンパスです。元の IPvlan モードと比較して、DataPath V2 モードは互換性が向上しています。詳細については、「Terway ネットワークプラグインを使用する」をご参照ください。
Terway ネットワーク Pod のライフサイクルを表示する方法
ACK コンソールにログインします。左側のナビゲーションウィンドウで、[クラスター] をクリックします。
クラスター ページで、目的のクラスターを見つけてその名前をクリックします。左側のペインで、 を選択します。
[DaemonSet] ページの上部で、
をクリックし、[kube-system] 名前空間を選択します。[DaemonSet] ページで、terway-eniip を検索し、[名前] リストの下にある terway-eniip をクリックします。
Pod の現在のステータスを次に示します。
タイプ
説明
準備完了
Pod 内のすべてのコンテナーが起動し、正常に実行されています。
保留中
Pod は Terway がネットワークリソースを構成するのを待っています。
ノードリソースが不足しているため、Pod はノードにスケジュールされていません。詳細については、「Pod の例外のトラブルシューティング」をご参照ください。
ContainerCreating
Pod はノードにスケジュールされており、Pod がネットワークの初期化が完了するのを待っていることを示します。
詳細については、「Pod のライフサイクル」をご参照ください。
Terway コンポーネントのアップグレード失敗に関するよくある質問
症状 | 解決策 |
アップグレード中にエラーコード | EIP 機能は Terway コンポーネントではサポートされなくなりました。この機能を引き続き使用するには、「Terway から ack-extend-network-controller への EIP の移行」をご参照ください。 |
Terway ネットワークモードで「MAC アドレスが見つかりません」というエラーで Pod の作成が失敗する
症状
MAC アドレスが見つからないというエラーで Pod の作成が失敗します。
failed to do add; error parse config, can't found dev by mac 00:16:3e:xx:xx:xx: not found解決策
システム内の NIC のロードは非同期です。CNI が構成されているときに、NIC が正常にロードされていない可能性があります。この場合、CNI は自動的にリトライし、問題は発生しないはずです。Pod の最終的なステータスを確認して、成功したかどうかを判断してください。
Pod が長時間作成に失敗し、上記のエラーが報告される場合、通常は ENI がアタッチされているときに高次メモリが不足しているためにドライバーのロードに失敗したことが原因です。インスタンスを再起動することで解決できます。
クラスタードメイン (ClusterDomain) の設定について知っておくべきこと
ACK クラスターのデフォルトの ClusterDomain は cluster.local です。クラスターを作成するときにクラスタードメインをカスタマイズすることもできます。次の点に注意してください。
ClusterDomain はクラスターの作成時にのみ構成でき、クラスターの作成後は変更できません。
クラスターの ClusterDomain は、クラスター内のサービスのドメインのトップレベルドメインです。これは、内部クラスターサービスの独立したドメイン解決ゾーンです。DNS 解決の競合を避けるために、ClusterDomain はクラスター外のプライベートまたはパブリック DNS ゾーンと重複してはなりません。