EKSを使うにあたって個人的に気になった点をまとめ。
- EKSとは
- EKSの開始方法
- k8sのバージョンアップ
- クラスターエンドポイントのアクセスコントロール
- プラットフォームのバージョン
- ワーカーノード
- ストレージ
- AutoScaling
- ロードバランシング
- ネットワーク
- クラスター認証の管理
- セキュリティ
- 確認しておくべきドキュメント
EKSとは
- AWSによるマネージドKubernetesサービス(以下k8s)
- AWSの機能と統合(IAM/リポジトリ/LBなど)
- OSSのk8sと完全互換性あり
コントロールプレーンのアーキテクチャ
- コントロールプレーンはクラスタごとに固有
- 別AWSアカウントやクラスタ間で共有しない
- 3つのAZにまたがっている
- VPCのSecurityGroupやNetworkACLでコントローウルプレーン間のトラフィックをクラスタ内にとどめている
EKSの開始方法
- eksctlを使う
- マネジメントコンソール使う
- その他
- terraform
- cloudformatin など
流れとしてはEKSクラスタ作成→ワーカーノード作成
3種類のクラスターVPCタイプ
- パブリックサブネット&プライベートサブネット
- 外部からアクセスをされるようなサービスに使う。パブリックをLB、プライベートをpodという感じ
- パブリックサブネットのみ
- 外部アクセスのみのサービスに使う
- プライベートサブネットのみ
- 内部でしかアクセスしないサービスに使う
プライベートクラスタの注意点
- eksctl はプライベートクラスターではサポートされていません。
- AWS X-Ray はプライベートクラスターではサポートされていません。
- AWS Fargate はプライベートクラスターではサポートされていません
- Amazon EKS の ALB Ingress Controller はプライベートクラスターでは機能しません
IAMユーザがk8sのRBACに追加される
Amazon EKS クラスターが作成されたら、クラスターを作成する IAM エンティティ (ユーザーまたはロール) は、管理者 (system:master アクセス許可が付与されている) として Kubernetes RBAC 認証テーブルに追加されます。最初は、その IAM ユーザーだけが kubectl を使用して Kubernetes API サーバーを呼び出すことができます。詳細については、「クラスターのユーザーまたは IAM ロールの管理」を参照してください。コンソールを使用してクラスターを作成する場合は、クラスター上で kubectl コマンドを実行する際、同じ IAM ユーザー認証情報が AWS SDK 認証情報チェーンにあることを確認する必要があります。
クラスタを作成したIAMユーザorロールがk8sのClusterAdminとして登録されるということですかね。
クラスタエンドポイントのアクセス
k8sのAPI Serverのアクセスをグローバルに公開するorしない の選択です
- パブリック
- クラスターの Kubernetes API サーバーエンドポイントへのパブリックアクセスのみを有効にします。クラスターの VPC の外部から送信される Kubernetes API リクエストは、パブリックエンドポイントを使用します。
- プライベート
- クラスターの Kubernetes API サーバーエンドポイントへのプライベートアクセスのみを有効にします。クラスターの VPC 内から送信される Kubernetes API リクエストは、プライベート VPC エンドポイントを使用します。
- パブリック＆プライベート
注意
- Amazon EBS ボリュームによってバックアップされ、Kubernetes Cluster Autoscaler を使用する複数のアベイラビリティーゾーンにわたってステートフルアプリケーションを実行している場合、それぞれが単一のアベイラビリティーゾーンにスコープされる複数のノードグループを設定する必要があります。また、--balance-similar-node-groups 機能を有効にする必要があります
- パブリックサブネットを選択した場合、インスタンスがクラスターに正常に参加するには、そのサブネットの MapPublicIpOnLaunch を true に設定する必要がある
- EKSではLBを作成するので、LBを作成するサブネットもクラスタに含める必要がある
k8sのバージョンアップ
Amazon EKS クラスターの Kubernetes バージョンの更新 - Amazon EKS
- Amazon EKS は、クラスターの更新時に Kubernetes アドオンを変更しません
- Kubernetes プロジェクトは、新機能、設計の更新、およびバグ修正とともに急速に進化しています。コミュニティでは、Kubernetes の新しいマイナーバージョン (例: 1. 17) をリリースしています。これは、およそ 3 か月ごとにリリースされており、各マイナーバージョンは、最初にリリースされてから約 9 か月間サポートされます。
クラスターエンドポイントのアクセスコントロール
- このエンドポイントは Kubernetes API サーバー用であり、AWS API と通信するための従来の AWS PrivateLink エンドポイントではないため、Amazon VPC コンソールではエンドポイントとして表示されません。
- クラスターのエンドポイントのプライベートアクセスを有効にすると、Amazon EKS によって自動的に Route 53 プライベートホストゾーンが作成され、それがクラスターの VPC に関連付けられます。このプライベートホストゾーンは Amazon EKS によって管理され、アカウントの Route 53 リソースには表示されません。
- 標準の Amazon EKS アクセス許可に加えて、IAM ユーザーまたはロールには、クラスターのエンドポイントのプライベートアクセスを有効にするための
route53:AssociateVPCWithHostedZoneアクセス許可が必要です。
プラットフォームのバージョン
k8sのマイナーバージョンと、eksのプラットフォームバージョンという２つの考え方があります。
マイナーというのは1.16や1.17というk8sのバージョンのことです。これに対してeksのプラットフォームバージョンというのは、AWSがk8sの1.16に対して、1.16.1とか1.16.7とかセキュリティパッチや機能拡張したようなものがでたときにそれを追うためのバージョンのことです。
例えば以下のような感じです。 * k8sの1.15.10 → 1.15のeks.1 * k8sの1.15.11 → 1.15のeks.2 * k8sの1.16.8 → 1.16のeks.1 (eksのバージョンはマイナーごとに別れている）
k8sのマイナーバージョンアップにともなうコントロールプレーンのアップグレード作業は、自動orユーザによる手動が選べますが、eksのバージョンアップは自動で行われます。
新しい Amazon EKS プラットフォームバージョンでは、重大な変更が発生したり、サービスが中断されたりすることはありません。
またeksのバージョンアップ時に新しいワーカーノード用のAMIが出ることがありますが、同じk8sマイナーバージョン用のAMIであればどのeksバージョンにも対応しているようです。
Amazon EKS は、対応するパッチバージョンを含む新しいワーカー AMI を発行する可能性があります。ただし、すべてのパッチバージョンは、特定の Kubernetes マイナーバージョンの EKS コントロールプレーンとワーカー AMI との間に互換性があります。
ワーカーノード
AMI
- EKS最適化Linux AMI
- Amazon Linux2
- docker/kubelet/IAMオーセンティケーターが含まれる
- 高速化用AMIあり
- EKS最適化Windows AMI
マネージド型ノードグループ
- Amazon EKS によって管理される Amazon EC2 Auto Scaling グループの一部としてプロビジョニングされる
- マネージド型ノードグループの一部として起動されたノードは、自動的に Kubernetes Cluster Autoscaler によって自動検出用にタグ付けされ、ノードグループを使用して、いつでも Kubernetes ラベルのノードへの適用と更新ができます
- マネージド型ノードグループの Auto Scaling グループは、グループの作成時に指定するすべてのサブネットにまたがる
セルフマネージド型ワーカーノード
- 自身でEC2を作成・管理して、オートスケーリンググループなどを設定する
- セルフマネージド型ノードグループにはカスタムネットワークを設定できますが、マネージド型ノードグループには設定できない
- ポッドのネットワークインターフェイスが、コントロールプレーンのセキュリティグループと同じ VPC 内にある別のセキュリティグループまたはサブネットを使用する必要があるユースケース など
Fargate
EKS+Fargateは色々制限があるので確認しておいた方が良い
- Classic Load Balancer および Network Load Balancer は Fargate で実行されているポッドではサポートされません。入力の場合は、Amazon EKS の ALB Ingress Controller (最小バージョン v1.1.4) を使用することをお勧めします。
- デーモンセットは Fargate ではサポートされていません。
ストレージ
Amazon EBS CSI ドライバー - Amazon EKS
- EBS用のストレージクラス作成用にプラグインがあるが、CSIの方の利用が推奨
- 2020/07時点ではCSIドライバは v0.5.0でベータ版
- ただし本番稼働用によってテスト＋サポートされる
- FargateでCSIドライバは利用できない
- Amazon EFS は伸縮自在なファイルシステムであるため、ファイルシステムの容量制限は強制されません。永続ボリュームと永続ボリュームクレームの実際のストレージ容量の値は、ファイルシステムを作成するときには使用されません。ただし、ストレージ容量は Kubernetes の必須フィールドであるため、この例では 5Gi などの有効な値を指定する必要があります。この値は、Amazon EFS ファイルシステムのサイズを制限しません。
AutoScaling
- Cluster Autoscaler - クラスタ内のノードの数を自動調整
- Cluster Autoscaler podをデプロイする
- Horizontal Pod Autoscaler - CPU/memに基づいてpodの数を自動調整
- Metrics Server podデプロイする
- k8sのhpaの機能を使う
- Vertical Pod Autoscaler - podのCPU/memの予約を自動調整
- Metrics Server podデプロイする
- Vertical Pod Autoscalerをデプロイする
ロードバランシング
- k8sの
type: LoadBalancerを通じてNLB/CLBをサポート - IngressとしてALBをサポート
ロードバランシング
- 内部ロードバランサーの場合、Amazon EKS クラスターは、VPC 内で少なくとも 1 つのプライベートサブネットを使用するように設定されている必要があります。Kubernetes は、サブネットがパブリックかプライベートかどうかをルートテーブルで調べます。パブリックサブネットには、インターネットゲートウェイを使ったインターネットへの直接の経路がありますが、プライベートサブネットにはありません。
ネットワーク
セキュリティグループ
- クラスタセキュリティグループ
- コントロールプレーンとマネージド型ノードグループからのすべてのトラフィックが相互に自由に流れるように設計されている
- クラスターセキュリティグループをコントロールプレーンのクロスアカウント Elastic Network Interface およびマネージド型ノードグループインスタンスに割り当てることにより、この通信を許可するために複雑なセキュリティグループルールを設定する必要がない
ポッドネットワーク
- Amazon VPC CNI を使用している
- 他のも使える 互換性のある代替 CNI プラグイン - Amazon EKS
- Calico
- Cilium
- Weave Net
- AWSとして公式サポートはAmazon VPC CNIのみ
- FargateやECSでいうawsvpcのネットワークタイプ
- 各インスタンスにpod用のENI/IPが付与される
外部ソースネットワークアドレス変換 (SNAT)
外部ソースネットワークアドレス変換 (SNAT) - Amazon EKS
トラフィックの宛先が VPC の外部のアドレスである場合に、Kubernetes の Amazon VPC CNI プラグインは各ポッドのプライベート IP アドレスを、そのポッドのデフォルトの Amazon EC2 インスタンスワーカーノードのプライマリ Elastic Network Interface に割り当てられたプライマリプライベート IP アドレスに変換します。
CNI Metrics Helper
- CNI メトリクスヘルパーは、Elastic Network Interface と IP アドレス情報を収集し、クラスターレベルでメトリクスを集計し、メトリクスを Amazon CloudWatch に発行するために使用できるツールです。
- Amazon EKS クラスターを管理するときは、割り当てられた IP アドレスの数と、使用可能な IP アドレスの数を調べることができます。CNI メトリクスヘルパーは、以下のために役立ちます。
- メトリクスを経時的に追跡する
- IP の割り当てと再利用に関連する問題をトラブルシューティングおよび診断する
- キャパシティープランニングに関する洞察を提供する
CNIのアップグレード
Amazon VPC CNI Plugin for Kubernetes のアップグレード - Amazon EKS
- Amazon EKS は、新しいバージョンがリリースされたときに、クラスター上の CNI プラグインを自動的にアップグレードしません
- 既存のクラスターで CNI プラグインの新しいバージョンを取得するには、プラグインを手動でアップグレードする必要があります
クラスター認証の管理
Amazon EKS では、Kubernetes クラスターの認証に (AWS CLI のバージョン 1.16.156 以降で使用可能な aws eks get-token コマンド、または AWS IAM Authenticator for Kubernetes を経由して) IAM を使用します。ただし、認証には、Kubernetes ネイティブのロールベースのアクセスコントロール (RBAC) を引き続き使用します。つまり、IAM は有効な IAM エンティティの認証にのみ使用されます。Amazon EKS クラスターの Kubernetes API とやり取りするためのアクセス許可はすべて、従来の Kubernetes RBAC システムを使用して管理されます。
セキュリティ
IAMロール
- EKSクラスタロール
- ワーカーロール - kubeletデーモンが使用するAWS API呼び出し。ワーカーノードやCNIポリシー、ECRへのアクセスなど
- pod実行ロール - Fargateで実行用に必要
- EC2上のpod単位にIAM権限を渡したいならk8sのServiceAccountに付与するIAMロール、ポリシーを使う
確認しておくべきドキュメント
公式
- Kubernetes サービスアカウントに対するきめ細やかな IAM ロール割り当ての紹介 | Amazon Web Services ブログ
- EKS Best Practices Guide for Security
- De-mystifying cluster networking for Amazon EKS worker nodes | Containers
非公式
- EKS を運用してみて感じた課題感 | Basicinc Enjoy Hacking!
- スマホゲームの API サーバにおける EKS の運用事例 | エンジニアブログ | GREE Engineering
- Amazon EKS Advent Calendar 2019 - Qiita
- EKSを本番環境で使う上で知っておいた方が良いこと（2019/12/12時点） - Qiita
- EKS production ready! part.1. awsにはeksというKubernetesのマネージドサービスが存在しています。… | by kengo suenaga | Medium
- Kubernetes on AWS/EKSベストプラクティス | JAWS DAYS 2019
www.slideshare.net
www.slideshare.net
