翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# 信頼性のベストプラクティス
このセクションでは、EKS で実行されているワークロードを回復力と高可用性にするためのガイダンスを提供します。
## このガイドの使い方
このガイドは、EKS で可用性と耐障害性に優れたサービスを開発して運用したい開発者やアーキテクトを対象としています。このガイドは、使いやすいようにさまざまなトピック領域にまとめられています。各トピックは簡単な概要から始まり、EKS クラスターの信頼性に関する推奨事項とベストプラクティスのリストが続きます。
## 序章
EKS の信頼性のベストプラクティスは、次のトピックにまとめられています。
+ アプリケーション
+ コントロールプレーン
+ データプレーン
システムの信頼性を高めるものは何ですか? 一定期間の環境の変化にもかかわらず、システムが一貫して機能し、需要を満たすことができる場合は、信頼性と呼ぶことができます。これを実現するには、システムは障害を検出し、自動的に修復し、需要に基づいてスケーリングできる必要があります。
お客様は、ミッションクリティカルなアプリケーションとサービスを確実に運用するための基盤として Kubernetes を使用できます。ただし、コンテナベースのアプリケーション設計原則を組み込むことに加えて、ワークロードを確実に実行するには、信頼性の高いインフラストラクチャも必要です。Kubernetes では、インフラストラクチャはコントロールプレーンとデータプレーンで構成されます。
EKS は、可用性と耐障害性に優れた本番稼働グレードの Kubernetes コントロールプレーンを提供します。
EKS では、AWS が Kubernetes コントロールプレーンの信頼性を担当します。EKS は、AWS リージョンの 3 つのアベイラビリティーゾーンで Kubernetes コントロールプレーンを実行します。Kubernetes API サーバーと etcd クラスターの可用性とスケーラビリティを自動的に管理します。
データプレーンの信頼性に対する責任は、ユーザー、顧客、AWS の間で共有されます。EKS には、Kubernetes データプレーンをデプロイするための 4 つのワーカーノードオプションが用意されています。
最もマネージド型のオプションである [EKS Auto Mode](https://docs.aws.amazon.com/eks/latest/userguide/automode.html) は、データプレーンのプロビジョニング、スケーリング、更新を処理し、マネージド型のコンピューティング、ネットワーキング、ストレージ機能を提供します。Auto Mode AMIs は頻繁にリリースされ、クラスターは CVE 修正とセキュリティパッチをデプロイするために最新の AMI に自動的に更新されます。Auto Mode NodePools で[中断](https://docs.aws.amazon.com/eks/latest/userguide/create-node-pool.html#_disruption)コントロールを設定することで、これが発生するタイミングを制御できます。
Fargate は、ノードごとに 1 つの Pod を実行して、データプレーンのプロビジョニングとスケーリングを処理します。3 番目のオプションであるマネージドノードグループは、データプレーンのプロビジョニングと更新を処理します。最後に、セルフマネージド型ノードはデータプレーンの最小マネージド型オプションです。使用する AWS マネージドデータプレーンが多いほど、責任は軽減されます。
[マネージド型ノードグループは](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-groups.html)、EC2 ノードのプロビジョニングとライフサイクル管理を自動化します。EKS API (EKS コンソール、AWS API、AWS CLI、CloudFormation、Terraform、または を使用`eksctl`) を使用して、マネージドノードを作成、スケーリング、アップグレードできます。マネージドノードは、アカウントで EKS 最適化 Amazon Linux 2 EC2 インスタンスを実行し、SSH アクセスを有効にすることでカスタムソフトウェアパッケージをインストールできます。マネージドノードをプロビジョニングすると、複数のアベイラビリティーゾーンにまたがることができる EKS マネージド Auto Scaling グループの一部として実行されます。これは、マネージドノードの作成時に指定したサブネットを介して制御します。また、EKS はマネージドノードに自動的にタグを付け、Cluster Autoscaler で使用できるようにします。
Amazon EKS は、マネージド型ノードグループで CVE およびセキュリティパッチの責任共有モデルに従います。マネージドノードは Amazon EKS に最適化された AMIs を実行するため、Amazon EKS はバグ修正時にこれらの AMIs のパッチ適用されたバージョンを構築する責任があります。ただし、これらのパッチが適用された AMI バージョンのマネージド型ノードグループへのデプロイはユーザーが担当します。
EKS [はノードの更新も管理します](https://docs.aws.amazon.com/eks/latest/userguide/update-managed-node-group.html)が、更新プロセスを開始する必要があります。[マネージドノードを更新する](https://docs.aws.amazon.com/eks/latest/userguide/managed-node-update-behavior.html)プロセスは、EKS ドキュメントで説明されています。
セルフマネージド型ノードを実行する場合は、[Amazon EKS 最適化 Linux AMI ](https://docs.aws.amazon.com/eks/latest/userguide/eks-optimized-ami.html)を使用してワーカーノードを作成できます。AMI とノードのパッチ適用とアップグレードはお客様の責任となります。`eksctl`、CloudFormation、または infrastructure をコードツールとして使用してセルフマネージドノードをプロビジョニングするのがベストプラクティスです。これにより、[セルフマネージドノードを簡単にアップグレード](https://docs.aws.amazon.com/eks/latest/userguide/update-workers.html)できるためです。ワーカーノードを更新するときは[、新しいノードへの移行](https://docs.aws.amazon.com/eks/latest/userguide/migrate-stack.html)を検討してください。移行プロセスによって古いノードグループが として**テイント**`NoSchedule`され、新しいスタックが既存のポッドワークロードを受け入れる準備ができたらノードが**ドレイン**されるためです。ただし、[セルフマネージドノードのインプレースアップグレード](https://docs.aws.amazon.com/eks/latest/userguide/update-stack.html)を実行することもできます。
**責任共有モデル - Fargate**
![\[責任共有モデル - Fargate\]](http://docs.aws.amazon.com/ja_jp/eks/latest/best-practices/images/reliability/SRM-Fargate.jpeg)
**責任共有モデル - MNG**
![\[責任共有モデル - MNG\]](http://docs.aws.amazon.com/ja_jp/eks/latest/best-practices/images/reliability/SRM-MNG.jpeg)
このガイドには、EKS データプレーン、Kubernetes コアコンポーネント、アプリケーションの信頼性を向上させるために使用できる一連の推奨事項が含まれています。
## フィードバック
このガイドは、より広範な EKS/Kubernetes コミュニティから直接フィードバックや提案を収集するために GitHub でリリースされています。ガイドに含める必要があると思われるベストプラクティスがある場合は、問題をファイルするか、GitHub リポジトリに PR を送信してください。サービスに新機能が追加されたとき、または新しいベストプラクティスが進化したときに、ガイドを定期的に更新する予定です。