Amazon Elastic Kubernetes Service (EKS) の利用方法(1/3)

Amazon EKS とは

https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/what-is-eks.html

Kubernetes（クーバネティス）は、コンテナオーケストレーションプラットフォームです。
コンテナは、アプリケーションやサービスを効率的かつ柔軟に実行するための軽量な仮想化技術であり、Kubernetesはそのコンテナを効果的に管理するための仕組みを提供します。

Kubernetesは、複数のコンテナが動作するクラスターを管理するための一連のAPIを提供し、
ノード上で実行されるコンテナの自動デプロイ、スケーリング、ロードバランシング、ネットワークルーティングなどの機能を提供します。
これにより、アプリケーションの高可用性やスケーラビリティが実現され、運用効率の向上が期待できます。

AWSでは、これらのサービスをマネージド型で提供しています。

今回の内容
メリット
リソースの分類(ワークロード、サービス、設定、ストレージ)
構築の流れ
1.Amazon EKSサービスロール作成
2.EKSクラスターVPCの作成
3.EKSクラスターの作成
4.ワーカーノードのデプロイ
kubectl get nodes

メリット

1. 操作の簡素化
EKSはKubernetesを完全にマネージドしており、クラスターのセットアップや管理を簡素化しています。これにより、クラスターのオペレーションにかかる時間やリソースを最小限に抑えることができます。
2. スケーラビリティ
EKSは、Kubernetesクラスターを自動的にスケールアップ/ダウンするための機能を提供しています。これにより、負荷が増えた場合でも、アプリケーションの可用性を維持できます。
3. 高可用性
EKSは、高可用性のために複数の可用ゾーンにわたってKubernetesクラスターをデプロイすることができます。これにより、1つの可用ゾーンに障害が発生しても、他の可用ゾーンでアプリケーションを実行できるため、アプリケーションの可用性を向上させます。
4. セキュリティ
EKSは、KubernetesのクラスターコントロールプレーンをAWSが管理するため、セキュリティの責任を共有できます。また、EKSはIAMやVPCなどのAWSサービスとの統合を提供しており、アプリケーションのセキュリティを強化することができます。
5. AWSサービスとの統合
EKSは、AWSの他のサービスとのシームレスな統合をサポートしています。たとえば、Amazon EC2インスタンスで実行されるKubernetesワーカーノードを起動するために、Amazon EBSやAmazon S3などのAWSサービスを使用できます。

VPCE（VPC Endpoint）を使用することで、Amazon EKSクラスター内のPodが、VPCエンドポイントを介して他のAWSサービスに安全にアクセスすることができます。PodがAWSサービスにアクセスする際には、VPCのNATゲートウェイやIGW（Internet Gateway）を経由する必要がなく、より安全で高速な接続が可能になります。

AWSのRDSに対するVPCEを使用する例

RDS用のVPCEを作成

aws ec2 create-vpc-endpoint --vpc-id <VPC_ID> --service-name com.amazonaws.<REGION>.rds --vpc-endpoint-type Interface --subnet-ids <SUBNET_ID> --security-group-ids <SECURITY_GROUP_ID>

VPCエンドポイントを使用してRDSに接続するためのPodのマニフェストの例(MySQL)
この例では、awsvpcネットワークモードを指定しています。また、envセクションでMySQLへの接続情報を定義しています。さらに、metadataセクションのannotationsに、RDSのVPCエンドポイントのARNを指定しています。これにより、PodはRDSに接続するために必要なVPCエンドポイントを自動的に特定することができます。

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: my-container
    image: nginx
    ports:
    - containerPort: 80
  securityContext:
    allowPrivilegeEscalation: false
    capabilities:
      drop:
      - ALL
  # awsvpcネットワークモードを指定し、VPCエンドポイントを利用する
  networkMode: "awsvpc"
  # RDSに接続するための環境変数を定義する
  env:
  - name: MYSQL_HOST
    value: <RDSのエンドポイント>
  - name: MYSQL_USER
    value: <ユーザー名>
  - name: MYSQL_PASSWORD
    valueFrom:
      secretKeyRef:
        name: <シークレット名>
        key: <パスワードのキー>
  dnsPolicy: "ClusterFirst"
  dnsConfig:
    options:
    - name: "ndots"
      value: "2"
  # VPCエンドポイントの参照
  metadata:
    annotations:
      # RDSのVPCエンドポイントARN
      "aws/vpc-endpoint-id": "vpce-0123456789abcdef0"

Podをデプロイする。

kubectl apply -f <MANIFEST_FILE>

これにより、PodはVPCEを介してRDSにアクセスすることができます。

EKS（Elastic Kubernetes Service）では、Podを自動スケールすることができます。
Podの自動スケーリングには、KubernetesのHorizontal Pod Autoscaler（HPA）を使用します。HPAはKubernetesのリソースの1つで、CPU使用率、API Objectのメトリクスなどをモニタリングし、 スケーリングが必要になったタイミングで、Replication ControllerやDeploymentなどのPod数をスケーリングします。 DaemonSetのようにスケールしないしない物に関してはHPAの対象とすることはできません。

Horizontal Pod Autoscaler (HPA)以外に、KubernetesのVertical Pod Autoscaler (VPA)やCustom Metrics APIを使用することもできます。Vertical Pod Autoscalerは、Podのリソース要件（CPU、メモリ）を自動的に調整することで、Podのパフォーマンスを最適化します。VPAは、Podのリソース使用量の統計情報を収集し、その情報を基に、Podのリソース要件を自動的に調整します。

Custom Metrics APIでは、ユーザーが独自に定義したメトリックスを使用して、Podの自動スケーリングを行うことができます。ユーザーは、PrometheusやCloudWatch Metricsなど、サポートされているメトリクスストレージソリューションからカスタムメトリクスを収集し、Custom Metrics APIを使用してそれらのメトリックスに基づいてPodのスケーリングを行うことができます。

リソースの分類(ワークロード、サービス、設定、ストレージ)

◆ワークロード
Kubernetesのワークロードとは、アプリケーションを実行するためのオブジェクトで、Pod、ReplicaSet、Deployment、StatefulSet、DaemonSetなどが含まれます。これらのオブジェクトは、コンテナを実行するために必要なリソースを定義します。

◆サービス
Kubernetesのサービスは、一連のPodに対して一意なDNS名とIPアドレスを提供するオブジェクトで、一般的には外部からのアクセスを可能にします。Serviceは、Podが動的に作成・削除される環境でも、一貫したアクセス先を提供することができます。Serviceのタイプには、ClusterIP、NodePort、LoadBalancer、ExternalNameがあります。

◆設定
Kubernetesの設定は、アプリケーションの設定情報を格納するオブジェクトで、ConfigMap、Secretが含まれます。ConfigMapは、アプリケーションの設定情報をKey-Valueの形式で格納するオブジェクトで、Secretは、機密情報を暗号化して格納するオブジェクトです。

◆ストレージ
Kubernetesのストレージは、コンテナの永続化に使用されるオブジェクトです。ストレージは、データを保持するために必要な永続化された領域を提供します。ストレージは、永続ボリューム（Persistent Volume、PV）と永続ボリュームクレーム（Persistent Volume Claim、PVC）の2つのオブジェクトで構成されます。さらに、StorageClassオブジェクトを使用することで、動的な永続ボリュームの作成を簡素化することができます。

「クラスタネットワーク」と「外部ネットワーク」があります。
Kubernetes内は「クラスタネットワーク」と呼ばれる「外部ネットワーク」とは異なるネットワークが構築されるので、単純に「クラスタネットワーク」内のPodへアクセスすることはできません。

Kubernetesのクラスタ内では、各ノードに割り当てられたIPアドレスに基づいて、クラスタネットワークが構築されます。このネットワークは、各ノード上で実行されるPod間の通信に使用されます。一方、外部ネットワークは、Kubernetesクラスタの外部にあるネットワークで、一般的にはインターネットを指します。

クラスタネットワークは、クラスタ内のPod間の通信に最適化されていますが、外部からのアクセスは制限されています。これは、クラスタネットワークには、クラスタ内のノードやPodにのみ割り当てられるプライベートIPアドレスが使用されるためです。外部からのアクセスを可能にするには、Kubernetesのサービスを使用して、クラスタネットワーク上のPodに公開する必要があります。

構築の流れ

手順は大きく分けて4つ

1.Amazon EKSサービスロール作成
2.EKSクラスターVPCの作成
3.EKSクラスターの作成
4.ワーカーノードのデプロイ

1.Amazon EKSサービスロール作成

EKSクラスターが他のAWSリソースに対してアクセスするためのロールを作成する

AWSマネジメントコンソールにサインインし、IAMダッシュボードに移動します。
左側のメニューから、「ロール」を選択します。
「ロールを作成する」ボタンをクリックします。
「AWSサービス」を選択し、「EKS」を選択します。
「次のステップ」をクリックします。
「権限」ページで、以下の2つのマネージドポリシーを追加します。
AmazonEKSServicePolicy
AmazonEKSClusterPolicy
「次のステップ」をクリックします。
「タグ」ページをスキップし、「ロール名」を入力します。
「ロールの作成」をクリックします。
これで、EKSサービスロールが作成されます。
このロールは、EKSクラスターが他のAWSリソースにアクセスするために必要な権限を持っています。EKSクラスターを作成する際に、このロールを使用してクラスターに権限を与えることができます。

2.EKSクラスターVPCの作成

EKSクラスターのVPCを作成する

1).AWSマネジメントコンソールにサインインし、Amazon VPCダッシュボードに移動します。
左側のメニューから、「VPC」を選択し、「VPCウィザードを起動する」をクリックします。
VPCの名前とCIDRブロックを入力します。CIDRブロックは、EKSクラスターで使用するPod IPアドレス範囲を含める必要があります。

2).パブリックサブネットとプライベートサブネットを作成するか、またはすでに存在するサブネットを使用するかを選択します。EKSクラスターで使用するサブネットを指定する必要があります。

3).インターネットゲートウェイを作成するか、すでに存在するものを使用するかを選択します。
EKSクラスターにインターネットアクセスが必要な場合は、インターネットゲートウェイを作成する必要があります。

4).ルートテーブルを作成するか、既存のルートテーブルを使用するかを選択します。
EKSクラスターで使用するルートテーブルを指定する必要があります。

5).セキュリティグループを作成するか、既存のセキュリティグループを使用するかを選択します。
EKSクラスターで使用するセキュリティグループを指定する必要があります。

6).VPCを作成してウィザードを完了します。

これで、EKSクラスターで使用するVPCが作成されます。
VPCのサブネット、ルートテーブル、セキュリティグループなどのリソースを適切に構成することで、EKSクラスターを構築するための基盤が整います。

3.EKSクラスターの作成

Amazon Elastic Kubernetes Service（EKS）クラスターを作成する

AWSマネジメントコンソールにサインインし、EKSダッシュボードに移動します。
「クラスターを作成する」をクリックします。
「クラスターの設定」で、クラスター名、リージョン、バージョンを指定します。
また、VPCとサブネット、およびアクセスコントロールに使用するIAMロールを選択します。
「ノードグループの設定」で、ノードグループの名前、インスタンスタイプ、AMIタイプ、およびノードグループに含めるインスタンスの数を指定します。
「ノードグループの詳細」で、ノードグループで使用するセキュリティグループ、ロール、およびキーペアを指定します。
「クラスターの設定の確認」で、作成するクラスターとノードグループの設定を確認します。
「作成」をクリックして、クラスターを作成します。

EKSクラスターが作成されるまでの時間は、クラスターのサイズや設定、リージョンなどによって異なりますが、通常は数分から10分程度です。

クラスター作成後には、kubectlなどのKubernetesツールを使用してクラスターにアクセスできます。また、AWSマネジメントコンソールのEKSダッシュボードから、クラスターのステータスやログ、ノードグループの詳細などを確認できます。

Amazon EKSは、ノードグループの自動スケーリング、パッチ管理、セキュリティパッチ適用、ログの収集などの機能を提供します。

4.ワーカーノードのデプロイ

EKS EC2クラスターにワーカーノードをデプロイする

1). 必要なIAMロールを作成する
ワーカーノードには、
AmazonEKSWorkerNodePolicy、
AmazonEC2ContainerRegistryReadOnly、
AmazonEKS_CNI_Policyの3つのIAMロールが必要です。
これらのロールは、EKSワーカーノードが必要とするAWSサービスへのアクセス許可を提供します。

2).ワーカーノードで使用するAmazon Machine Image (AMI) を選択する。
EKSノード用のAMIを選択する必要があります。AWSは、EKS-optimized AMIを提供しています。

3). ワーカーノードグループを作成する

◆セキュリティグループの作成
ワーカーノードグループで使用するセキュリティグループを作成します。セキュリティグループは、インバウンドおよびアウトバウンドのトラフィックを制御します。
例えば、以下のようにAWS CLIを使用してセキュリティグループを作成できます。

aws ec2 create-security-group --group-name my-security-group --description "My security group" --vpc-id <vpc-id> 

◆Launch Templateの作成
ワーカーノードグループで使用するLaunch Templateを作成します。Launch Templateは、EC2インスタンスの設定を定義します。AMI、インスタンスタイプ、ユーザーデータなどのパラメータを指定できます。
以下の例は、Launch Templateを作成するAWS CLIのコマンドです。

aws ec2 create-launch-template --launch-template-name my-launch-template --version-description "My version" --instance-type t3.small --image-id ami-0xxxxxx 

◆Auto Scaling Groupの作成
最後に、Auto Scaling Groupを作成してワーカーノードグループを管理します。Auto Scaling Groupは、指定されたLaunch Templateを使用してEC2インスタンスを起動および管理します。
以下の例は、Auto Scaling Groupを作成するAWS CLIのコマンドです。

aws autoscaling create-auto-scaling-group --auto-scaling-group-name my-asg --launch-template "LaunchTemplateName=my-launch-template,Version=1" --min-size 2 --max-size 10 --desired-capacity 2 --vpc-zone-identifier <subnet-ids> --tags "Key=Name,Value=my-node-group,PropagateAtLaunch=true" 

作成されたワーカーノードグループは、EKSクラスターに自動的に登録されます。

4). kubelet設定を更新する
kubelet-config-1.18.yamlファイルを作成します。このファイルは、kubeletの設定をカスタマイズするために使用されます。

cat <<EOF > kubelet-config-1.18.yaml kind: KubeletConfiguration apiVersion: kubelet.config.k8s.io/v1beta1 cgroupDriver: systemd EOF 

kubeletのConfigMapを作成します。

kubectl create configmap kubelet-config-1.18 --from-file=kubelet-config-1.18.yaml 

5). ノードグループをEKSクラスターに紐づける
AWS CLIを使用して、ノードグループをEKSクラスターに紐づけます。

aws eks update-kubeconfig --name <cluster_name> 

Nodeグループのkubeconfigを作成します。

aws eks describe-cluster --name <cluster_name> --query "cluster.status.endpoint" --output text aws eks describe-cluster --name <cluster_name> --query "cluster.certificateAuthority.data" --output text | base64 -d > ca.crt aws eks update-kubeconfig --name <cluster_name> --kubeconfig aws-auth.yaml 

aws-auth ConfigMapを更新します。
次のコマンドで、ConfigMapを編集します。

kubectl edit configmap aws-auth -n kube-system 

編集したaws-auth ConfigMapに、ノードグループのARNを追加します。

apiVersion: v1 data: mapRoles: | - rolearn: <worker_node_role_arn> username: system:node:{{EC2PrivateDNSName}} groups: - system:bootstrappers - system:nodes 

6). ワーカーノードがEKSクラスターに正常に登録されているか確認する
次のコマンドを使用して、ワーカーノードがEKSクラスターに正常に登録されているか確認します。

kubectl get nodes

クラスターに登録されているノードの一覧が表示されます。各ノードの状態（Ready 等）やリソース使用状況なども確認できます。
コマンドを実行した場合の出力例

$ kubectl get nodes

NAME        STATUS   ROLES    AGE     VERSION
node-1      Ready    <none>   1d      v1.21.3
node-2      Ready    <none>   1d      v1.21.3
node-3      Ready    <none>   1d      v1.21.3

この例では、クラスタに node-1、node-2、node-3 という3つのノードが存在し、すべてが Ready ステータスであることがわかります。
また、これらのノードにはいずれも特定の役割が割り当てられていないこと < none > や、ノードの稼働時間 (AGE) なども確認出来ます。

Amazon Elastic Kubernetes Service (EKS) の利用方法(1/3)
https://qiita.com/kimuni-i/items/656ca4d314a8982e70cb

Amazon Elastic Kubernetes Service (EKS) の利用方法(2/3)
https://qiita.com/kimuni-i/items/06c70de226cf074d8b23

Amazon Elastic Kubernetes Service (EKS) の利用方法(3/3)
https://qiita.com/kimuni-i/items/b2b3d07c2c76c95884a1