Kubernetes のよくある落とし穴と課題 10 選

Kubernetes は、最も人気のあるコンテナ オーケストレーションおよびデプロイメント プラットフォームです。その強力な機能により、コンテナ化されたアプリケーションを本番環境で確実に実行できるようになります。

ただし、柔軟性には複雑さが伴います。この記事では、多くのチームが遭遇する Kubernetes の一般的な落とし穴を 10 個取り上げます。これらの課題を特定して回避できれば、アプリケーションのスケーラビリティ、信頼性、セキュリティが向上すると同時に、クラスターとそのデプロイメントをより細かく制御できるようになります。

1. 最新のタグを使用してコンテナをデプロイする

Kubernetes で最も頻繁に違反されるベストプラクティスの 1 つは、コンテナをデプロイするときに最新のタグを使用することです。これにより、システムの安定性に影響を与える可能性のある重大な変更を誤って受け入れてしまうリスクが生じます。

最新タグの使い方は人それぞれですが、ほとんどの人は latest をプロジェクトの最新バージョンに指定します。たとえば、今日 helm:latest を使用すると Helm v3 が提供されますが、v4 がリリースされた後に再起動すると v4 に更新されますが、システムはまだ v3 を実行していると認識され、予期しないリスクが発生する可能性があります。

2. 生存性および準備性プローブを使用していない

プローブを使用すると、アプリケーションの回復力を高めることができます。これらは、Kubernetes に Pod の健全性を通知します。

コンテナ内でメモリ オーバーフローや Liveness プローブ要求のタイムアウトなどの問題が発生すると、Liveness プローブは Kubernetes に通知してコンテナを再起動させます。

アプリケーションが一時的にリクエストに応答できなくなる場合があります。たとえば、アプリケーションの起動時に大量のデータや構成ファイルを読み込む必要がある場合や、起動後に外部サービスを待機する必要がある場合があります。この場合、アプリを強制終了したくはありませんが、アプリにリクエストを送信したくもありません。 Kubernetes は、このような状況を検出して軽減するための準備プローブを提供します。コンテナが配置されているポッドは、準備ができていないことを報告し、Kubernetes サービス経由のトラフィックを受け入れません。

以下は、有効性と準備状況のプローブを備えたシンプルな Pod です。

 apiVersion: v1 kind: Pod metadata: name: probes-demo spec: containers: - name: probes-demo image: nginx:latest livenessProbe: httpGet: path: / port: 80 readinessProbe: httpGet: path: / port: 80

3. ノードセレクタが不足しているため、スケジューリング効率が低下する

クラスターの全体的なパフォーマンスは、ポッドが適切なノードに正しくスケジュールされているかどうかによって決まります。多くのクラスターには、標準アプリケーション用の小さな 2 CPU/4 GB ノードや、集中的なバックエンド サービス用の大きな 8 CPU/16 GB ノードなど、複数のタイプのノードが含まれています。

ポッドを必要なノード プールに確実にスケジュールできない場合、クラスターの使用率は低くなります。たとえば、十分に活用されていない小さなノードがある場合でも、不要な新しい大きなノードが強制的に作成され、クラスターのコストが増加する可能性があります。この問題を回避するには、ノードにラベルを設定し、ノード セレクターを使用して各 Pod を互換性のあるノードに割り当てます。

 apiVersion: v1 kind: Pod metadata: name: pod-node-selector-demo spec: containers: - name: nginx image: nginx:latest nodeSelector: node-class: 2c4g

このポッドは、ラベル node-class: 2c4g を持つノードにのみスケジュールされます。

一致するノードにラベルを設定するには、次のコマンドを使用します: kubectl label

適切なスケジューリング ルールを設定すると、ノードの使用率が最大化され、安定したクラスター パフォーマンスが維持されます。

4. ポッドのアフィニティ/アンチアフィニティルールの違反

ポッド アフィニティ ルールとアンチ アフィニティ ルールを使用すると、ポッドのデプロイに最適なノードを Kubernetes に指示できます。ルールは、ノード レベルの特性 (ラベルなど) またはノード上ですでに実行されている他のポッドの特性に基づいて条件付けできます。

アフィニティ ルールはポッドをノードに引き寄せ、ポッドが特定のノードにスケジュールされる可能性を高めますが、反アフィニティは反発効果があり、スケジュールされる可能性を減らします。 Kubernetes は、スケジュール可能な各ノードの Pod アフィニティ ルールを評価し、最も適切なルールを選択します。

アフィニティ システムは複雑なスケジューリング動作をサポートできますが、アフィニティ ルールを誤って構成し、ポッドが誤って間違ったノードにスケジュールされたり、スケジュールを拒否されたりすることもよくあります。

たとえば、サービスの 2 つのコピーを 2 つのノードにスケジュールしておくと、1 つのノードに障害が発生した場合でも、サービスのもう 1 つのコピーが確実に利用可能になります。ルールが正しく設定されておらず、両方が 1 つのノードにスケジュールされている場合、サービスは利用できなくなります。

5. 監視・録音なし

Kubernetes でアプリケーションをスケーリングする場合、クラスター リソースの使用率、アプリケーション エラー、リアルタイムのパフォーマンス データを理解することが重要です。メモリ消費の急増、Pod の削除、コンテナのクラッシュはすべて注意すべき問題ですが、標準の Kubernetes には障害が発生したときに警告する監視機能がありません。

クラスターの監視を有効にするには、Prometheus、Nightingale などの可観測性プラットフォームをデプロイする必要があります。これにより、Kubernetes からメトリックが収集され、Grafana で関連するデータ メトリックが表示されます。アラーム機構も付いています。

6. ラベルセレクタが一致しません

デプロイメントやサービスなどのオブジェクトは、管理するポッドやその他のオブジェクトを識別するために正しいラベルセレクターに依存します。セレクターとオブジェクトに実際に割り当てられたラベルが一致しないと、デプロイメントが失敗します。

例：

 apiVersion: apps/v1 kind: Deployment metadata: name: demo-deployment spec: replicas: 2 selector: matchLabels: app: nginx-demo-app template: metadata: labels: # Label does not match the deployment's selector! app: nginx-demo-application spec: containers: name: nginx-demo-app image: nginx:latest

上記のファイルのデプロイメントでは、セレクターがテンプレート ラベルと一致しない spec.selector.matchLabelsspec.template.metadata.labels がスローされます。この問題を解決するには、マニフェストの および フィールドを調整して、同じキーと値のペアを持つようにします。

7. サービスポートの不一致

同様に、サービスがトラフィックをポッド上の正しいポートにルーティングするようにすることも重要です。ポート定義が正しくないと、実際にはトラフィックがそのポッドにまったく到達していないにもかかわらず、ポッドに障害が発生したように見えることがあります。

次のリストにはこの問題の例が含まれています。サービスはポート 9000 でリッスンし、トラフィックをポッドのポート 8080 に転送しますが、コンテナは実際にはポート 80 にあるため、トラフィックはコンテナに到達できません。

 apiVersion: v1 kind: Pod metadata: name: demo-pod labels: app: demo-app spec: image: nginx:latest ports: - containerPort: 80 --- apiVersion: v1 kind: Service metadata: name: demo-service spec: ports: - port: 9000 protocol: TCP targetPort: 8080 selector: app: demo-app

8. 誤って間違った名前空間にデプロイする

Kubernetes 名前空間は、一連のサービスを論理的にグループ化し、クラスター内での分離レベルを提供します。各チーム、アプリケーション、環境ごとに名前空間を作成すると、名前の競合を防ぎ、管理エクスペリエンスを簡素化できます。

名前空間を使用する場合は、各サービスと Kubectl コマンドのターゲット名前空間を指定することを忘れないでください。それ以外の場合は、デフォルトの名前空間 default が使用されます。サービスが適切な名前空間にデプロイされていない場合、関連するサーバー要求に到達できなくなります。

次のリストは、Istio Ingress 転送構成です。このファイルはセグメント スペースにデプロイされ、/dp-manager 要求に基づいてセグメント スペース内の dp-manager-backend サービスに転送されます。 dp-manager-backend がセグメント空間内にない場合、リクエストは異常になります。

 apiVersion: networking.istio.io/v1beta1 kind: VirtualService metadata: name: dp-manager-vs namespace: seg spec: gateways: - dp-manager-gateway hosts: - control-dpmanager.test.com http: - match: - uri: prefix: /dp-manager route: - destination: host: dp-manager-backend port: number: 80

9. リソ​​ース要求や制限のないポッド

クラスターの安定性を維持するには、適切なリソース管理が重要です。ポッドには、設定しない限り、デフォルトではリソース制限がないため、ノードの CPU とメモリが枯渇する可能性があります。

リソースの競合を減らすために、すべてのポッドに適切なリソース要求と制限を設定します。十分な容量を提供できないノードにポッドがスケジュールされないように、Kubernetes にポッド用に特定の量のリソースを予約するように要求します。制限は、ポッドが使用できるリソースの最大量を設定します。 CPU 制限を超えるポッドは調整され、メモリ制限に達するとメモリ不足 (OOM) エラーが発生し、ポッドが終了します。

リクエストと制限はPodマニフェストフィールドspec.container.resourcesで定義されます。

 apiVersion: v1 kind: Pod metadata: name: demo-pod spec: containers: - name: demo-container image: nginx:latest resources: requests: cpu: 100m memory: 1Gi limits: memory: 2Gi

上記の Pod は、100m (1000m は 1 コアに相当) の CPU 時間と 1Gi のメモリを要求します。十分なリソースを提供できるノードにのみスケジュールされます。 Pod はメモリ制限も設定しており、適用できる最大メモリは 2Gi です。ポッドのメモリ制限をそのリクエストと同じに設定するのがベストプラクティスです。 Kubernetes はリクエストを超過した Pod を比例的に制限するため、通常、CPU 制限は必要ありません。

10. クラスタ自動拡張エラー

Kubernetes を選択する理由の 1 つは、その柔軟な拡張性です。適切な構成により、 Kubernetes は需要がピークに達したときに新しいポッドとノードを自動的に追加し、水平方向および垂直方向に動的にスケーリングできるようになります。残念ながら、多くのチームにとって、自動スケーリングは予測不可能です。

したがって、クラスターの使用率を定期的にチェックして、それがまだワークロードに適しているかどうかを確認してください。 Locust などの負荷テスト ツールを使用して、自動スケーリング ルールをテストし、余分なトラフィックをクラスターに誘導します。これにより、問題を早期に検出し、実際のトラフィックが到着したときにポッドをシームレスにスケールアップできるようになります。