翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# クラスターサービス
クラスターサービスは EKS クラスター内で実行されますが、ユーザーワークロードではありません。Linux サーバーを使用している場合は、ワークロードをサポートするために、NTP、syslog、コンテナランタイムなどのサービスを実行する必要があります。クラスターサービスは似ており、クラスターの自動化と運用に役立つサービスをサポートしています。Kubernetes では、これらは通常 kube-system 名前空間で実行され、一部は [DaemonSets](https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/) として実行されます。
クラスターサービスは稼働時間が長く、停止中やトラブルシューティングに不可欠なことがよくあります。コアクラスターサービスが利用できない場合、停止 (ディスク使用率が高いなど) の回復や防止に役立つデータにアクセスできなくなる可能性があります。これらは、別のノードグループや 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..svc.cluster.local
api.example.svc.cluster.local
api.example.cluster.local
api.example..compute.internal
```
`namespace` と の`region`値は、ワークロードの名前空間とコンピューティングリージョンに置き換えられます。クラスターの設定に基づいて、追加の検索ドメインがある場合があります。
CoreDNS へのリクエストの数を減らすには、ワークロードの [ndots オプションを下げる](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pod-dns-config)か、末尾に を含めてドメインリクエストを完全に認定します (例: `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 ](https://kubernetes.io/docs/tasks/administer-cluster/nodelocaldns/)または[クラスター比例オートスケーラー](https://github.com/kubernetes-sigs/cluster-proportional-autoscaler)を使用して CoreDNS をスケールすることをお勧めします。
NodeLocal DNS では、クラスター内のより多くのコンピューティングリソースを必要とする DaemonSet としてノードごとに 1 つのインスタンスを実行する必要がありますが、DNS リクエストの失敗を回避し、クラスター内の DNS クエリの応答時間を短縮できます。クラスター比例オートスケーラーは、クラスター内のノードまたはコアの数に基づいて CoreDNS をスケーリングします。これはクエリをリクエストするための直接的な相関関係ではありませんが、ワークロードとクラスターサイズによっては便利です。デフォルトの比例スケールでは、クラスター内の 256 コアまたは 16 ノードのいずれか早い方ごとにレプリカを追加します。
[CoreDNS EKS アドオン](https://docs.aws.amazon.com/eks/latest/userguide/managing-coredns.html)を使用する場合は、[自動スケーリング](https://docs.aws.amazon.com/eks/latest/userguide/coredns-autoscaling.html)オプションを有効にすることを検討してください。CoreDNS オートスケーラーは、 (ノード÷16) または (CPU コア÷256) を最大とする式を使用してノード数と CPU コアをモニタリングすることで CoreDNS レプリカの数を動的に調整し、必要に応じてすぐにスケールアップし、安定性を維持するために徐々にスケールダウンします。
## Kubernetes メトリクスサーバーを垂直方向にスケールする
Kubernetes メトリクスサーバーは、水平スケーリングと垂直スケーリングをサポートしています。Metrics Server を水平方向にスケーリングすることで可用性は高くなりますが、より多くのクラスターメトリクスを処理するために水平方向にスケーリングされることはありません。ノードと収集されたメトリクスがクラスターに追加されるため、メトリクスサーバー[は推奨事項](https://kubernetes-sigs.github.io/metrics-server/#scaling)に基づいて垂直方向にスケールする必要があります。
Metrics Server は、収集、集計、処理するデータをメモリに保持します。クラスターが大きくなると、Metrics Server が保存するデータの量が増えます。大規模なクラスターでは、メトリクスサーバーは、デフォルトのインストールで指定されたメモリと CPU 予約よりも多くのコンピューティングリソースを必要とします。[Vertical Pod Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler) (VPA) または [Addon Resizer](https://github.com/kubernetes/autoscaler/tree/master/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](https://coredns.io/plugins/health/) 期間を設定することで、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](https://docs.fluentbit.io/manual/pipeline/filters/kubernetes) では、Use\_Kubelet を有効にして Kubernetes API Server ではなくローカル kubelet からメタデータを取得し、データをキャッシュできる場合に繰り返される呼び出しを減らす数値 (60 など) `Kube_Meta_Cache_TTL`に設定することをお勧めします。
スケーリングのモニタリングとログ記録には、次の 2 つの一般的なオプションがあります。
+ 統合を無効にする
+ サンプリングとフィルタリング
ログメタデータが失われるため、統合を無効にすることはオプションではないことがよくあります。これにより、API スケーリングの問題はなくなりますが、必要に応じて必要なメタデータがないため、他の問題が発生します。
サンプリングとフィルタリングは、収集されるメトリクスとログの数を減らします。これにより、Kubernetes API へのリクエストの量が減り、収集されるメトリクスとログに必要なストレージの量が減ります。ストレージコストを削減することで、システム全体のコストを削減できます。
サンプリングを設定する機能はエージェントソフトウェアに依存し、さまざまな取り込みポイントに実装できます。API サーバーの呼び出しが発生する可能性が高いため、可能な限りエージェントの近くにサンプリングを追加することが重要です。サンプリングサポートの詳細については、プロバイダーにお問い合わせください。
CloudWatch と CloudWatch Logs を使用している場合は、 [ドキュメントで説明](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/FilterAndPatternSyntax.html)されているパターンを使用してエージェントフィルタリングを追加できます。
ログとメトリクスが失われないようにするには、受信エンドポイントで停止した場合にデータをバッファできるシステムにデータを送信する必要があります。fluentbit を使用すると、[Amazon Kinesis Data Firehose](https://docs.fluentbit.io/manual/pipeline/outputs/firehose) を使用してデータを一時的に保持できるため、最終的なデータストレージの場所が過負荷になる可能性が低くなります。