クラスターサービス

クラスターサービスは EKS クラスター内で実行されますが、ユーザーワークロードではありません。Linux サーバーを使用している場合は、ワークロードをサポートするために、NTP、syslog、コンテナランタイムなどのサービスを実行する必要があります。クラスターサービスは似ており、クラスターの自動化と運用に役立つサービスをサポートしています。Kubernetes では、これらは通常 kube-system 名前空間で実行され、一部は DaemonSets として実行されます。

クラスターサービスは稼働時間が長く、停止中やトラブルシューティングに不可欠なことがよくあります。コアクラスターサービスが利用できない場合、停止 (ディスク使用率が高いなど) の回復や防止に役立つデータにアクセスできなくなる可能性があります。これらは、別のノードグループや AWS Fargate などの専用コンピューティングインスタンスで実行する必要があります。これにより、クラスターサービスが、スケールアップ中またはより多くのリソースを使用しているワークロードによって共有インスタンスに影響されないようになります。

CoreDNS のスケーリング

CoreDNS のスケーリングには、主に 2 つのメカニズムがあります。CoreDNS サービスへの呼び出しの数を減らし、レプリカの数を増やします。

ndot を下げて外部クエリを減らす

ndots 設定は、DNS のクエリを回避するのに十分なドメイン名の期間 (a.k.a. "dots") の数を指定します。アプリケーションの ndots 設定が 5 (デフォルト) で、api.example.com (2 ドット) などの外部ドメインからリソースをリクエストすると、CoreDNS は、より具体的なドメインの /etc/resolv.conf で定義された検索ドメインごとにクエリされます。デフォルトでは、外部リクエストを行う前に次のドメインが検索されます。

api.example.<namespace>.svc.cluster.local
api.example.svc.cluster.local
api.example.cluster.local
api.example.<region>.compute.internal

namespace と のregion値は、ワークロードの名前空間とコンピューティングリージョンに置き換えられます。クラスターの設定に基づいて、追加の検索ドメインがある場合があります。

CoreDNS へのリクエストの数を減らすには、ワークロードの ndots オプションを下げるか、末尾に を含めてドメインリクエストを完全に認定します (例: api.example.com. )。ワークロードが DNS 経由で外部サービスに接続する場合は、ワークロードで不要なクラスター DNS クエリが発生しないように、ndot を 2 に設定することをお勧めします。ワークロードがクラスター内のサービスへのアクセスを必要としない場合は、別の DNS サーバーと検索ドメインを設定できます。

spec:
  dnsPolicy: "None"
  dnsConfig:
    options:
      - name: ndots
        value: "2"
      - name: edns0

ndot を低すぎる値に下げた場合、または接続しているドメインに十分な特異度 (末尾の を含む) が含まれていない場合、DNS ルックアップは失敗する可能性があります。この設定がワークロードにどのように影響するかをテストしてください。

CoreDNS を水平方向にスケールする

CoreDNS インスタンスは、デプロイにレプリカを追加することでスケールできます。NodeLocal DNS またはクラスター比例オートスケーラーを使用して CoreDNS をスケールすることをお勧めします。

NodeLocal DNS では、クラスター内のより多くのコンピューティングリソースを必要とする DaemonSet としてノードごとに 1 つのインスタンスを実行する必要がありますが、DNS リクエストの失敗を回避し、クラスター内の DNS クエリの応答時間を短縮できます。クラスター比例オートスケーラーは、クラスター内のノードまたはコアの数に基づいて CoreDNS をスケーリングします。これはクエリをリクエストするための直接的な相関関係ではありませんが、ワークロードとクラスターサイズによっては便利です。デフォルトの比例スケールでは、クラスター内の 256 コアまたは 16 ノードのいずれか早い方ごとにレプリカを追加します。

Kubernetes メトリクスサーバーを垂直方向にスケールする

Kubernetes メトリクスサーバーは、水平スケーリングと垂直スケーリングをサポートしています。Metrics Server を水平方向にスケーリングすることで可用性は高くなりますが、より多くのクラスターメトリクスを処理するために水平方向にスケーリングされることはありません。ノードと収集されたメトリクスがクラスターに追加されるため、メトリクスサーバーの推奨事項に基づいてメトリクスサーバーを垂直方向にスケールする必要があります。

Metrics Server は、収集、集計、処理するデータをメモリに保持します。クラスターが大きくなると、Metrics Server が保存するデータの量が増えます。大規模なクラスターでは、メトリクスサーバーは、デフォルトのインストールで指定されたメモリと CPU 予約よりも多くのコンピューティングリソースを必要とします。Vertical Pod Autoscaler (VPA) または Addon Resizer を使用して、メトリクスサーバーをスケーリングできます。Addon Resizer はワーカーノードに比例して垂直方向にスケールし、VPA は CPU とメモリの使用量に基づいてスケールします。

CoreDNS lameduck の期間

ポッドは名前解決に kube-dnsサービスを使用します。Kubernetes は送信先 NAT (DNAT) を使用して、ノードから CoreDNS バックエンドポッドにkube-dnsトラフィックをリダイレクトします。CoreDNS デプロイをスケールすると、 はノードの iptables ルールとチェーンkube-proxyを更新して、DNS トラフィックを CoreDNS ポッドにリダイレクトします。CoreDNS をスケールアップするときに新しいエンドポイントを伝播し、スケールダウンするときにルールを削除すると、クラスターのサイズに応じて 1～10 秒かかることがあります。

この伝達遅延により、CoreDNS ポッドが終了してもノードの iptables ルールが更新されていない場合、DNS ルックアップが失敗する可能性があります。このシナリオでは、ノードは終了した CoreDNS Pod に DNS クエリを送信し続ける場合があります。

CoreDNS ポッドで Lameduck 期間を設定することで、DNS ルックアップの失敗を減らすことができます。 CoreDNS Lameduck モードの間、CoreDNS は処理中のリクエストに引き続き応答します。Lameduck 期間を設定すると、CoreDNS シャットダウンプロセスが遅延し、ノードが iptables ルールとチェーンを更新するために必要な時間を確保できます。

CoreDNS lameduck 期間を 30 秒に設定することをお勧めします。

CoreDNS 準備状況プローブ

CoreDNS の準備状況プローブ/healthには、 /ready の代わりに を使用することをお勧めします。

Lameduck 期間を 30 秒に設定し、ポッドの終了前にノードの iptables ルールを更新するのに十分な時間を提供するという以前の推奨事項に沿って、 CoreDNS 準備状況プローブ/ready/healthの代わりに を使用することで、起動時に CoreDNS ポッドが DNS リクエストに迅速に応答する準備が完全に整います。

readinessProbe:
  httpGet:
    path: /ready
    port: 8181
    scheme: HTTP

CoreDNS Ready プラグインの詳細については、https://coredns.io/plugins/ready/ を参照してください。

エージェントのログ記録とモニタリング

エージェントは API サーバーにクエリを実行してワークロードメタデータでログとメトリクスを強化するため、エージェントのログ記録とモニタリングによってクラスターコントロールプレーンに多大な負荷がかかる可能性があります。ノード上のエージェントは、コンテナやプロセス名などを表示するために、ローカルノードリソースにのみアクセスできます。API サーバーをクエリすると、Kubernetes デプロイ名やラベルなどの詳細を追加できます。これはトラブルシューティングに非常に役立ちますが、スケーリングに悪影響を及ぼす可能性があります。

ログ記録とモニタリングにはさまざまなオプションがあるため、すべてのプロバイダーの例を表示することはできません。fluentbit では、Use_Kubelet を有効にして Kubernetes API Server ではなくローカル kubelet からメタデータを取得し、データをキャッシュできる場合に繰り返される呼び出しを減らす数値 (60 など) Kube_Meta_Cache_TTLに設定することをお勧めします。

スケーリングのモニタリングとログ記録には、次の 2 つの一般的なオプションがあります。

• 統合を無効にする

• サンプリングとフィルタリング

ログメタデータが失われるため、統合を無効にすることは多くの場合、オプションではありません。これにより、API スケーリングの問題は排除されますが、必要に応じて必要なメタデータがないため、他の問題が発生します。

サンプリングとフィルタリングは、収集されるメトリクスとログの数を減らします。これにより、Kubernetes API へのリクエストの量が減り、収集されるメトリクスとログに必要なストレージの量が減ります。ストレージコストを削減することで、システム全体のコストを削減できます。

サンプリングを設定する機能はエージェントソフトウェアに依存し、さまざまな取り込みポイントに実装できます。API サーバーの呼び出しが発生する可能性が高いため、可能な限りエージェントの近くにサンプリングを追加することが重要です。サンプリングサポートの詳細については、プロバイダーにお問い合わせください。

CloudWatch と CloudWatch Logs を使用している場合は、ドキュメントで説明されているパターンを使用してエージェントフィルタリングを追加できます。

ログとメトリクスが失われないようにするには、受信エンドポイントで機能停止が発生した場合にデータをバッファできるシステムにデータを送信する必要があります。fluentbit を使用すると、Amazon Kinesis Data Firehose を使用してデータを一時的に保持できるため、最終的なデータストレージの場所が過負荷になる可能性が低くなります。