Kubernetes アンチパターンを回避するためのガイド

Kubernetes を使い始めたばかりでも、アプリケーションでの使用を検討している場合でも、Kubernetes が分散型でスケーラブル、高可用性のクラウドネイティブ アプリケーションを管理するための強力なツール セットであることはご存じでしょう。しかし、多くの人がよくある間違いを犯しています。

この記事では、Kubernetes を使用する際に最もよくある落とし穴をいくつか取り上げ、それらを回避するためのヒントを紹介します。

リソース要求が設定されていません

これは間違いなく最も注目すべき点であり、このリストの 1 位にランクされています。

多くの場合、CPU 要求は設定されていないか、非常に低く設定されているため (各ノードに多数のポッドを配置できるようにするため)、ノードが過負荷になります。需要が高い場合、ノードの CPU が使い果たされ、ワー​​クロードは要求されたリソースしか取得できなくなります。 CPU が調整され、アプリケーションで遅延やタイムアウトが発生します。

BestEffort (使用しない方がよい):

 resources: {}

CPU をほとんど使用しない (できれば使用しない):

 resources: requests: cpu: "1m"

一方、ノードの CPU が完全に使用されていない場合でも、CPU 制限によってポッドの動作に不必要な制約が課せられ、レイテンシが増加する可能性があります。

Linux カーネルの CPU CFS クォータ、および CPU 設定制限と CFS クォータの無効化に基づく CPU スロットリングについては、多くの議論が行われてきました。

CPU スロットリングは、解決するよりも多くの問題を引き起こす可能性があります。

メモリの過剰使用はさらなる問題を引き起こす可能性があります。 CPU 制限に達するとスロットルが発生し、メモリ制限に達するとポッドが強制終了されます。 OOMkillを見たことがありますか?そうです、そういう意味です。このようなことが起こる頻度を最小限に抑えたいですか?次に、メモリをオーバーコミットせず、次の例のように、保証された QoS を使用してメモリ要求をメモリ制限と等しく設定します。これについてはHenning Jacobs（Zalando）[3]の講演で詳しく読むことができます。

バースト可能（OOMkill される可能性が高くなります）:

 resources: requests: memory: "128Mi" cpu: "500m" limits: memory: "256Mi" cpu: 2

保証:

 resources: requests: memory: "128Mi" cpu: 2 limits: memory: "128Mi" cpu: 2

では、リソースを設定するときに何が役立つでしょうか?

metrics-server を使用すると、ポッド (およびそのコンテナ) の現在の CPU およびメモリの使用状況を表示できます。おそらくすでにこれを使用していると思いますが、次のコマンドを実行するだけです。

 kubectl top pods kubectl top pods --containers kubectl top nodes

ただし、現在の使用量のみが表示されます。それは便利で、大まかな見当をつけてくれますが、最終的には使用状況のメトリックをリアルタイムで確認したいのです (ピーク時や昨日の朝の CPU 使用率はどのくらいだったかなどの質問に答えるため)。この目的のために、Prometheus、DataDog、その他多くのツールを使用できます。これらのツールは、メトリック サーバーからメトリックを取得して保存するだけで、クエリを実行してグラフ化できます。

VerticalPodAutoscaler[4]は、このプロセスを自動化し、CPU /メモリの使用状況をリアルタイムで監視し、これらの条件に基づいて新しいリソース要求と制限をリセットするのに役立ちます。

コンピューターを効果的に使用するのは簡単ではありません。常にテトリスをプレイしているようなものです。平均使用率が低い（たとえば、約 10%）のにコンピューティングに多額の費用を支払っている場合は、サーバーレス/従量課金モデルを活用し、より安価になる可能性がある AWS Fargate または Virtual Kubelet ベースのサービスを検討することをお勧めします。

ヘルスチェックを省略

Kubernetes にサービスをデプロイする場合、ヘルスチェックはサービスの維持に重要な役割を果たします。

Kubernetes 環境では、ヘルスチェックはあまり活用されていません 😿。ヘルスチェックを使用すると、ポッドとそのコンテナの健全性を監視できます。

Kubernetes にはヘルスチェック用の主要なツールが 3 つあります。

• Liveness Check を使用すると、Kubernetes はアプリケーションが稼働中かどうかを確認できます。各ノードで実行されている Kubelet エージェントは、ライブネス プローブを使用して、コンテナーが期待どおりに実行されていることを確認します。
• 準備チェックはコンテナのライフサイクル全体を通じて実行され、Kubernetes はこのプローブを使用してコンテナがトラフィックを受け入れる準備が整ったかどうかを把握します。
• 起動プローブは、コンテナ アプリケーションが正常に起動したかどうかを判断し、起動チェックが失敗した場合はポッドを再起動します。

最新のタグを使用する

この質問は非常に古典的です。最新のタグは説明が不十分で使いにくいです。 Kubernetes のドキュメントでは、images:latest ラベルの付いたコンテナを本番環境で使用することについて明確に説明されています。

コンテナを本番環境にデプロイする場合は、実行中のイメージのバージョンを追跡したりロールバックしたりすることが困難になるため、:latest タグの使用を避ける必要があります。

最近は、多くの人が何度も被害に遭い、:latest の使用をやめて、全員が修正バージョンに固執するようになったため、このようなことはあまり見られません。

ECRにはラベル不変性の優れた機能[5]があり、ぜひ試してみる価値があります。

コンテナの権限が高すぎる

過剰なコンテナ権限とは、通常のコンテナがアクセスできないリソースにアクセスできるなど、コンテナに過剰な権限が付与されることを意味します。

これは、開発者が Kubernetes を使用する際によく犯す間違いであり、セキュリティ上のリスクをもたらします。

たとえば、Docker コンテナ内で Docker デーモンを実行することは特権コンテナの例ですが、特権コンテナは必ずしも安全ではありません。

これを回避するには、カーネルの脆弱性全体の 25% 以上を占める CAP_SYS_ADMIN 機能をコンテナに提供しないようにすることをお勧めします。

また、コンテナに完全な権限とホスト ファイル システムの権限を付与しないようにすることも重要です。これらの 2 つの権限により、コンテナが悪意のあるバイナリを置き換えることでホスト全体を侵害する可能性があるためです。

コンテナに過剰な権限が付与されないようにするには、権限設定を慎重に構成し、必要以上の権限でプロセスを実行しないようにする必要があります。

さらに、監視とログ記録を通じて問題を検出し解決することも重要です。

監視とログ記録の欠如

Kubernetes 環境で監視とログ記録が不足すると、セキュリティと全体的なパフォーマンスが低下する可能性があります。ログ記録と監視が不十分だと、インシデントの調査と対応が困難になり、問題を効果的に発見して解決することが難しくなります。

よくある落とし穴は、関連するログやメトリックが不足しているために、Kubernetes プラットフォームとアプリケーションの障害点を見つけることができないことです。

これに対処するには、Prometheus、Grafana、Fluentd、Jaeger などの適切な監視およびログ記録ツールを設定して、メトリック、ログ、トレースを収集、分析、視覚化し、Kubernetes 環境のパフォーマンスと健全性に関する洞察を得ることが不可欠です。

強力な監視とログ記録のプラクティスを実装することで、組織は情報を効果的に相関させ、より深い洞察を得て、Kubernetes 環境のダイナミクスと複雑さに関連する課題を克服できます。

すべてのオブジェクトはデフォルトの名前空間を使用します

Kubernetes 内のすべてのオブジェクトにデフォルトの名前空間を使用すると、組織上および管理上の課題が生じます。

デフォルトの名前空間は、サービスとアプリケーションが作成されるデフォルトの場所であり、明示的に指定されない限りアクティブな名前空間でもあります。

デフォルトの名前空間に完全に依存すると、クラスター内のさまざまなコンポーネントまたはチーム間の分離と組織化が欠如し、リソース管理、アクセス制御、および可視性が困難になります。これを回避するには、Kubernetes クラスター内での組織化、リソース割り当て、アクセス制御を改善するために、さまざまなプロジェクト、チーム、またはアプリケーションごとにカスタム名前空間を作成することをお勧めします。

複数の名前空間を利用することで、ユーザーはリソースを効果的にセグメント化して管理し、Kubernetes 環境の全体的な運用効率とセキュリティを向上させることができます。

セキュリティ構成の欠如

アプリケーションを展開するときは、常にセキュリティを念頭に置く必要があります。では、セキュリティに関して考慮すべき最も重要なことは何でしょうか?たとえば、クラスターの外部からアクセス可能なエンドポイントの使用、シークレットの保護の欠如、特権コンテナを安全に実行する方法を考慮していないことなどです。

Kubernetes セキュリティは、あらゆる Kubernetes デプロイメントの不可欠な部分です。セキュリティ上の課題には次のようなものがあります。

• 承認 - 認証と承認は、Kubernetes クラスター内のリソースへのアクセスを制御するために重要です。
• ネットワーキング - Kubernetes ネットワーキングでは、オーバーレイ ネットワークとサービス エンドポイントを管理して、コンテナー間のトラフィックがクラスター内で安全にルーティングされるようにします。
• ストレージ - クラスター内のストレージを保護し、許可されていないユーザーやプロセスがデータにアクセスできないようにします。

Kubernetes API サーバーには、保存されているすべての情報へのアクセスを提供する REST インターフェースがあります。つまり、ユーザーは API に HTTP リクエストを送信するだけで、API に保存されているあらゆる情報にアクセスできます。認証されていないユーザーがこのデータにアクセスできないようにするには、ユーザー名/パスワードやトークンベースの認証などの方法を使用して、API サーバーの認証を構成する必要があります。

これは、クラスター自体のセキュリティだけでなく、クラスター上のシークレットと構成のセキュリティについても言えます。クラスターを脆弱性から保護するには、クラスター上で一連のセキュリティ制御を構成する必要があります。

ロールベースのアクセス制御 (RBAC) を使用して Kubernetes クラスターを保護することは、そのような強力なセキュリティ制御の 1 つです。ロールベースのアクセス制御は、ユーザーに割り当てられたロールに基づいてリソースへのアクセスを制限することで、Kubernetes クラスターのセキュリティを確保するのに役立ちます。これらのロールは、「管理者」または「オペレーター」として設定できます。

管理者ロールには完全なアクセス権がありますが、オペレーター ロールにはクラスター内のリソースに対する制限された権限があります。この方法で、クラスターにアクセスできるユーザーを制御および管理できます。

PodDisruptionBudgetが見つかりません:

Kubernetes 上で本番ワークロードを実行する場合、ノードとクラスターをアップグレードまたは廃止する必要があることがよくあります。 PodDisruptionBudget (pdb) は、クラスター管理者とクラスター ユーザー間のサービス保証 API です。

ノード枯渇による不要なサービス中断を回避するために、必ず pdb を作成してください。

 apiVersion: policy/v1 kind: PodDisruptionBudget metadata: name: db-pdb spec: minAvailable: 2 selector: matchLabels: app: database

クラスター ユーザーは、クラスター管理者に次のように伝えることができます。「ここにデータベース サービスがあり、どのような場合でも少なくとも 2 つのレプリカを常に利用できるようにしたいです。」

ポッドのアンチアフィニティ機能:

たとえば、デプロイメントの 3 つのポッド レプリカを実行している場合、ノードがダウンすると、すべてのレプリカもダウンします。どういう意味ですか？すべてのレプリカは 1 つのノードで実行されますか? Kubernetes は HA を提供するのではないですか?

Kubernetes スケジューラがポッドのアンチアフィニティを強制することは期待できません。明示的に定義する必要があります。

 ...... labels: app: db ...... affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: "app" operator: In values: - db topologyKey: "kubernetes.io/hostname"

それでおしまい。これにより、ポッドが異なるノードにスケジュールされることが保証されます (実行時ではなくスケジュール時にのみチェックされるため、requiredDuringSchedulingIgnoredDuringExecution を構成する必要があります)。

ここでは、異なるアベイラビリティーゾーンではなく、異なるノード上の podAntiAffinity - topologyKey: "kubernetes.io/hostname" について説明します。適切な HA が本当に必要な場合は、このトピックを読んでください。

すべてのHTTPサービスの負荷分散

クラスター内には、外部に公開したい http サービスが多数存在する場合があります。

Kubernetes サービスをタイプ: LoadBalancer として公開すると、そのコントローラー (ベンダー固有) が外部ロードバランサーをプロビジョニングして構成しますが、これらのリソースは大量に作成する必要があるため、高価になる可能性があります (外部の静的 IPv4 アドレス、コンピューティング、秒単位の料金など)。

この場合、同じ外部ロード バランサーを共有し、サービスを type: NodePort として公開するか、さらに良い方法として、nginx-ingress-controller (または traefik や Istio) のようなものを外部ロード バランサーに公開された単一の NodePort エンドポイントとしてデプロイし、Kubernetes Ingress リソースに基づいてクラスター全体にトラフィックをルーティングする方が合理的です。

クラスター内の他の (マイクロ) サービスは、すぐに使用できる ClusterIP サービスと DNS サービス検出を介して通信できます。

レイテンシやクラウド コストに影響する可能性があるため、パブリック DNS/IP を使用しないように注意してください。

Kubernetes 非対応のネットワーク対応クラスタの自動拡張

クラスターにノードを追加または削除するときには、ノードの CPU 使用率などの単純なメトリックを考慮する必要はありません。ポッドをスケジュールするときは、多数のスケジュール制約 (ポッドとノードの親和性、汚染と許容範囲、リソース要求、QoS など) に基づいて決定を行う必要がありますが、外部の自動スケジューラがこれらの制約を認識していない場合は問題が発生する可能性があります。

スケジュールする必要がある新しいポッドがあるが、使用可能な CPU がすべて要求されており、ポッドが「保留中」状態のままになっているとします。外部オートスケーラーは、現在使用されている平均 CPU (要求された CPU ではない) を認識するため、スケーリングはトリガーされず (新しいノードは追加されません)、ポッドのスケジュール設定に失敗します。

スケールダウン（クラスターからノードを削除すること）は常に困難です。ステートフル ポッド (永続ボリュームが接続された) があるとします。永続ボリュームは通常、特定のアベイラビリティーゾーンに属するリソースであり、リージョン内にレプリカがないため、カスタム オートスケーラーはこのポッドを含むノードを削除します。また、永続ストレージを持つ唯一のアベイラビリティーゾーンによって大幅に制限されるため、スケジューラーはそれを別のノードにスケジュールできません。ポッドは再び保留状態のままになります。

コミュニティでは、クラスター内で実行され、ほとんどの主要なパブリッククラウドプロバイダーのAPIと統合され、すべての制限を理解し、上記の状況でスケールアップするcluster-autoscaler[6]が広く使用されています。また、設定した制約に違反することなく適切にスケールダウンすることで、計算オーバーヘッドも節約できます。

結論は

要約すると、Kubernetes はコンテナ化されたアプリケーションを管理するための強力なツールですが、独自の課題もあります。よくある間違いや落とし穴を避けるためには、Kubernetes とのやり取りに細心の注意を払い、デプロイされたサービスとのやり取りの違いを理解することが重要です。

すべてが自動的に実行されるとは思わないでください。アプリケーションをクラウドネイティブにするために時間を投資してください。これらの間違いを避けることで、Kubernetes のデプロイメントを効率的に完了し、Kubernetes 環境の安定性、パフォーマンス、セキュリティを向上させることができます。

参考文献:

[1]Kubernetes を使用する際に避けるべき最も一般的な間違い: アンチパターン: https://medium.com/@seifeddinerajhi/most-common-mistakes-to-avoid-when-using-kubernetes-anti-patterns-%EF%B8%8F-f4d37586528d

[2]Kubernetes実践演習ハンズオン: https://github.com/seifrajhi/Kubernetes-practical-exercises-Hands-on

[3]コスト効率とレイテンシの高負荷に対するKubernetesリソース要求/制限の最適化: https://www.slideshare.net/try_except_/optimizing-kubernetes-resource-requestslimits-for-costefficiency-and-latency-highload

[4]VerticalPodAutoscaler: https://cloud.google.com/kubernetes-engine/docs/concepts/verticalpodautoscaler

[5]Amazon ECR が不変イメージタグをサポートするようになりました: https://aws.amazon.com/about-aws/whats-new/2019/07/amazon-ecr-now-supports-immutable-image-tags

[6]cluster-autoscaler: https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler