コンテナーが開始されない理由

次の問題のうち 1 つ以上が確認されます。

ワーカー・ノードで新しいポッドを作成できません。ワーカー・ノードへのポッドのデプロイは成功するが、コンテナーが ContainerCreating の状態のまま変わらない。

ContainerCreating 状態のポッドに対して kubectl describe pod <pod> を実行すると、以下のいずれかのようなイベントが表示されます。

Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "XXX": failed to request 1 IPv4 addresses. IPAM allocated only 0

desc = failed to create pod network sandbox ... error adding container to network "k8s-pod-network": cannot allocate new block due to per host block limit

以下のコマンドを実行すると、1 つ以上の calico-node ポッドがワーカー・ノードで開始に失敗し、 CrashLoopBackOff 状態になります。

1.29 以降の場合:
```
kubectl logs -n calico-system <calico-node_pod>
```
1.28 以前の場合:
```
kubectl logs -n kube-system <calico-node_pod>
```
ログの最後の行には、以下のメッセージが含まれています。
```
Unable to autoassign an address - pools are likely exhausted. type="ipipTunnelAddress"
```

症状のリストにある IP アドレス関連メッセージがいずれも表示されない場合は、レジストリー割り当て量に達したためにコンテナーが開始されていない可能性があります。

症状にリストされている IP アドレス関連メッセージのいずれかが表示される場合は、Calico プラグイン用の IP Address Manager (IPAM) によって、クラスター内のすべてのポッド IP アドレスが使用中であると誤検知されるために、コンテナーが開始されない可能性があります。 Calico IPAM は使用可能な IP アドレスを検出しないためクラスター内の新規ポッドに IP アドレスを割り当てないので、ポッドは開始できません。

レジストリー割り当て量問題の解決

仮想プライベート・クラウドクラシック・インフラストラクチャー

レジストリーの割り当て量の問題を解決するには、IBM Cloud Container Registry のストレージを解放してください。

IP アドレス問題の解決

仮想プライベート・クラウドクラシック・インフラストラクチャー

IP アドレスの問題を解決するには、Calico IPAM レコードから正常に削除されていない個々の IP アドレスと IP アドレス・ブロックを解放して、クラスターのポッドで再使用できるようにしてください。

ご使用のクラスターでは、サポートされているバージョンを実行する必要があります。クラスターで非推奨または非サポートのバージョンが実行されている場合は、最初にクラスターを更新してください。

ステップ 1: 個々の IP アドレスを解放する

まずは、Calico IPAM レコードから正常に削除されていない個々の IP アドレスがないか確認し、あればクラスターのポッドで再使用可能にするために解放します。

Calico CLI のインストールおよび構成の手順に従って、バージョン 3.18 以降の calicoctl クライアントをダウンロードし、ご使用のクラスターにとって正しい Calico 構成を使用して、その Calico 構成がターゲット・クラスターに対して正しく機能していることを確認します。クラスターで古いバージョンの Calicoが実行されている場合でも、 calicoctl バージョン 3.18 を使用して以下の手順のコマンドを実行できます。

最近クラシック・クラスターを Kubernetes バージョン 1.18 から 1.19 に更新した場合、クラスターでは Calico 用に KDD データ・ストアが使用されます。 1.19 バージョンのクラスター向けのステップに従って、DATASTORE_TYPE 環境変数を kubernetes に設定し、KUBECONFIG 環境変数をご使用のクラスター用の kube-config ファイルに設定してください。古い calicoctl.cfg は、以下のステップでは機能しない etcd 内の古くなったデータを指しています。
Calico IPAM で使用中として誤検知される IP アドレスがないか確認します。
```
calicoctl ipam check
```

出力で、Scanning for IPs that are allocated but not actually in use... という行が含まれたセクションを探します。 IP アドレスが IPAM で割り振られているが、実際には使用されていない場合は、次のステップに進んでそれらを解放します。この出力例では、181 個の IP アドレスを解放できます。

...
Scanning for IPs that are allocated but not actually in use...
Found 181 IPs that are allocated in IPAM but not actually in use.
Scanning for IPs that are in use by a workload or node but not allocated in IPAM...
Found 0 in-use IPs that are not in active IP pools.
Found 0 in-use IPs that are in active IP pools but have no corresponding IPAM allocation.

Check complete; found 181 problems.

これまでポッド・エンドポイントに割り当てられていた IP アドレスを Calico IPAM から解放します。以下の手順でデータ・ストアをロックした後は既存のポッドは引き続き実行されますが、作成されたポッドはいずれも ContainerCreating 状態のままであるため、データ・ストアをアンロックするまでは、作成されたポッドは開始できないことに注意してください。このデータ・ストア・ロックにより、IP アドレスの解放中に IPAM レコードが変更されることが防止されます。詳しくは、 Calico オープン・ソースの資料を参照してください。
1. Calico IPAM レコードのデータ・ストアをロックします。
```
calicoctl datastore migrate lock
```
2. IPAM のチェック結果を保存します。
```
calicoctl ipam check -o report.json
```
3. 未使用の IP アドレスを解放します。このプロセスは、解放する必要がある IP アドレスの数に応じて、最大で 20 分間かかることがあります。
```
calicoctl ipam release --from-report=report.json
```
4. データ・ストアをアンロックします。
```
calicoctl datastore migrate unlock
```
5. 未使用の IP アドレスがすべて解放されていることを確認します。
```
calicoctl ipam check
```
  出力例
```
Check complete; found 0 problems.
```
オプション: データ・ストアが正常にアンロックされ、IP アドレスの割り当てが可能になったことを確認するために、ポッドを作成し、そのポッドが正しく起動することを確認します。
1. 例えば、単純な NGINX ポッドを作成します。
```
kubectl run test --image=nginx --generator=run-pod/v1
```
2. ポッドが IP アドレスを割り当てられて、正常に実行されていることを確認します。
```
kubectl get po test
```
3. テスト・ポッドを削除します。
```
kubectl delete pod test
```
次のセクションに進み、使用されていない IP アドレス・ブロックがないか確認します。

ステップ 2: IP アドレス・ブロックを解放する

次は、ワーカー・ノードに割り当てられているのにそのワーカー・ノードで使用されていない IP アドレス・ブロックがないか確認し、あればブロック全体をクリーンアップします。

場合によっては、ワーカー・ノードに 2 つ目または 3 つ目の IP アドレス・ブロックが割り当てられると、そのワーカー・ノードでそれまで使用されていた IP アドレス・ブロック全体が、後で完全に未使用状態になることがあります。また、ワーカー・ノードを削除または置換するときに、calico-kube-controllers を一時的に実行するために使用できるワーカー・ノードが存在しなかった、あるいは、CNI プラグインや containerd ランタイムで問題が発生したために、Calico IPAM が IP アドレス・ブロックをクリーンアップできなかった可能性もあります。

Kubernetes バージョン 1.19 以降を実行しているすべてのクラシック・クラスターと、すべての VPC クラスターについては、IP ブロックが空いている状況を確保することが特に重要です。これらのクラスターでは、strictAffinity という Calico 設定は true に設定されます。これにより、ワーカー・ノードは自身に割り当てられた IP ブロック内の IP アドレスを使用するように強制されて、他のワーカー・ノードに割り当てられたブロック内の IP アドレスを使用できなくなります。徐々に、ノードに割り当てられたのに使用されていないブロックが蓄積していき、最終的に、ワーカー・ノードに割り当て可能な IP アドレス・ブロックがなくなる場合があります。

個々の IP アドレスを解放する手順を実行します。
Calico IPAM レコードのデータ・ストアをロックするかどうかを選択します。
- データ・ストアをロックした場合は既存のポッドは引き続き実行されますが、作成されたポッドはいずれも ContainerCreating 状態のままであるため、データ・ストアをアンロックするまでは、作成されたポッドは開始できません。このようにデータ・ストアをロックした場合は、未使用ブロックの確認後、ブロックを解放するまでは、ポッドを作成できなくなります。
- データ・ストアをロックしない場合は、削除した解放済みブロックの IP アドレスを使用した新規ポッドが存在しないことを直ちに確認する必要があります。
```
calicoctl datastore migrate lock
```
Calico IPAM レコードをリストします。出力で、IPS IN USE の数が 0 であるブロックを探します。このようなブロックは、そのブロックが割り当てられたワーカー・ノードで使用されていません。
```
calicoctl ipam show --show-blocks
```
この出力例では、172.24.10.64/26 ブロックには使用中の IP アドレスはありません。
```
...
Block    | 172.24.10.64/26  |        64 | 0 (0%)     | 64 (100%)  |
...
```
このようなブロックのそれぞれについて、以下の手順を実行してブロックを解放します。
1. ブロック内の IP アドレスが現在どのポッドでも使用されていないことを確認します。
```
kubectl get pods -A
```
2. ブロックの BlockAffinity を取得します。ブロック内のピリオドとスラッシュをハイフン (-) で置き換えます。例えば、ブロック 172.24.10.64/26 の場合、以下のコマンドのフォーマットは 172-24-10-64-26 となります。
```
kubectl get blockaffinity | grep <block>
```
3. BlockAffinityを削除します。
```
kubectl delete blockaffinity <block_affinity>
```
4. ブロックの IPAMBlock を取得します。ブロック内のピリオドとスラッシュをハイフン (-) で置き換えます。例えば、ブロック 172.24.10.64/26 の場合、以下のコマンドのフォーマットは 172-24-10-64-26 となります。
```
kubectl get ipamblock | grep <block>
```
5. IPAMBlockを削除します。
```
kubectl delete ipamblock <ipam_block>
```
6. ステップ 2 でデータ・ストアをロックしなかった場合: BlockAffinity と IPAMBlock の削除前に、ポッドが直接作成されなかったことを確認します。ポッドが作成された場合は、このブロックの BlockAffinity と IPAMBlock を再度削除する必要があります。次に、 kubectl delete pod <pod> を実行して、このブロック内の IP アドレスを使用するすべてのポッドを削除し、別のブロックの IP アドレスでポッドが再作成されるようにします。
```
kubectl get pods -A
```
7. IPS IN USE が 0 である他のブロックについて、この手順を繰り返します。
ステップ 2 でデータ・ストアをロックした場合: データ・ストアをアンロックします。
```
calicoctl datastore migrate unlock
```