はじめに

「おぼろげながら浮かんできたんです。EKSという単語が。」

なんとなくですが、EKSを使ってみたくなったので使ってみました。EKSというのはAWSで使用できるkubernetesのサービスです。AWSにはEKSの他にもECSというAWSが独自に用意したコンテナのオーケストレーションツールも存在します。
学習コストの低さやメンテナンスの運用などを考えると、自分は試すならECSからかな、と今になっては思うんですがしょうがありません。なぜなら、おぼろげながら浮かんじゃったから。。。

Kubernetesとは何？

この記事を読んでいる聡明な皆様なら既に知っていると思いますが、念のためKubernetesについても説明します。（「クバネティス」、「クーバネティス」と読みます。私はどや顔で「くー↑ばねいつ↓」と読んでいました）

Kubernetes (K8s)は、デプロイやスケーリングを自動化したり、コンテナ化されたアプリケーションを管理したりするための、オープンソースのシステムです。
引用：kubernetes公式ドキュメント

一見するとよくわかりませんが、三回ぐらい読んでもよくわかりません。
皆さんはアプリをコンテナ化したことはあるでしょうか？
では、複数のコンテナをアプリとしてデプロイした際のコンテナ同士の連携、リソースの管理、デプロイなどを経験したことはあるでしょうか？
これらの工程にはかなりの工数がかかり、経験豊富な方でないと難しい部分があります。
（実はそういった経験がないので何がそんなにめんどくさいのかピンと来ていません）

そいつをバシッと解決してくれるのがKubernetesになります。
Kubernetesは、複数コンテナの運用を考えたときに出てくるそういっためんどくさい部分をなんかうまいぐわいにやってくれる機能、という理解で大丈夫です。
そのような機能を相称して「オーケストレーションツール」と呼びます。

EKSとは

EKSはAWSでKubernetesを実行できるサービスになります。
といっても、AWSのコンソール上でバチバチに開発するというわけではなく、適当なサーバーからアクセスしてEKSを操作することになります。
kubectlというKubernetesをコマンドで操作するためのツールがあるのですが、こちらを開発に用います。
Kubernetesに慣れている人にとっては、新たに勉強する必要がなく、スムーズにEKSに移行できるためこちらの仕様は大変ありがたいものになります。

今まで通りコマンドで開発、見通しの良いコンソール上で作成したリソース等の確認って使い方が一番いいんでしょうか。

コントロールプレーンとワーカー

kubernetesはコントロールプレーンと複数のワーカーで構成されます。
コントロールプレーンとワーカーとまとめてクラスタと呼びます。
ワーカーは、コンテナを入れるところ、コントロールプレーンはワーカーとコンテナを管理するところです。

例えば、複数のワーカーにコンテナとして同一のアプリをデプロイしたとします。
複数の人からアプリにアクセスがあったときに常に同じワーカー（サーバー）のコンテナを動かしていたらそのサーバーのリソースがすぐに枯渇してしまいそうですよね。
そんな時、コントロールプレーンが、それらしくリソースを分配してくれます。

また、そのようなアプリをアップデートする際には、ローリングアップデートという技術を使うこともできます。
複数ワーカーのコンテナを一度にアップデートするのではなく、一つ一つ順番にアップデートすることで、アプリを停止させることなくアップデートが可能になります。その制御もコントロールプレーンが担っています。

料金

皆さん気になりだしてるのがこちらだと思います。料金体系。
比較のためにAWSにある同じオーケストレーションツールであるECSの値段も載せておきます。

機能名	クラスタ	ワーカー
EKS	月 : 74$	EC2 or Fargate の料金
ECS	月 : 0$	EC2 or Fargate の料金

EKSはクラスタを作成すると一時間当たり0.10$、大体月に74$ かかります。
ところがどっこい、ECSは0$と中々太っ腹です。

ワーカーは結局サーバーなのでAWSにあるサーバーの機能を利用することになります。どのサーバーを利用するかによってその料金は変わります。

メンテナンス

これからEKSの導入を考えている人には絶対知っておいてほしい事項です。
EKSはKubernetesを利用しているため、その機能はKubernetesのバージョンに依存しています。

そのバージョン管理が問題でして、EKSでは約三か月に一回マイナーバージョンがリリースされます。
しかし、各バージョンのサポート期限はリリースされてから一年間であり、その期限が来る前にクラスタ及びワーカーのEKSバージョンの更新を行う必要があるんです。

仮に今使っている機能の仕様が急に変わったり使えなくなったりなどの可能性を考えると、こちらはかなりのメンテナンスコストが要求されると考えられます。

ところがどっこい、ECSにはバージョンという概念が存在しません。
ECSでは、アップデートによって使えなくなる機能もなければ、定期的な更新作業も必要ないです。
なんかいつの間にか便利機能が追加されてるから、使ってみよーってノリで新しい機能を試すことができます。

ネットワークの設定

ここまで聞くと、「EKSとECSだったらECSの方が良さそう。。。」といった意見が出そうですがそちらの考えは早計です。

ワーカーにコンテナをデプロイする、コンテナ同士を連携するといったときに、適宜ネットワークを引く必要があります。
こちらの設定をEKSは全て自動でやってくれるのに対し、ECSでは適宜自分で設定する必要があります。
クラスタの規模が大きくなり、サービスが複雑になるにつれ、そのネットワークの管理工数というのはどんどん増えていきます。

以上を踏まえると、サービスが複雑になるのであればEKS、シンプルになるのであればECSを採用するのが無難だと思います。

この記事の目的

何となく浮かんできたEKSという単語ですが、とりあえず複数ノードにまたがるアプリを実装してみようと思いました。
で、アプリに関しては普段使い慣れてるReactアプリをとりあえずデプロイしてみようと思います。

最終的な形としては、複数ノードにコンテナ化したReact App + Nginxをぶち込むということで実現しようと思います。

手順

事前準備

　EKSでは、適当なサーバーからアクセスして操作する必要があるので、まずはそのサーバーの準備を行います。
私は操作する端末として、とりあえずローカルに入っていたWSL Ubuntu20.04を用いました。

aws-cliのインストール

$ pip install awscli

aws-cliの設定

aws configure
 AWS Access Key ID [None]: ＜アクセスキー＞
 AWS Secret Access Key [None]: ＜シークレットキー＞
 Default region name [None]: ap-northeast-1
 Default output format [None]: json

eksctlのインストール（AWS EKSと接続したりするための独自のもの）

$ curl --silent --location "https://github.com/weaveworks/eksctl/releases/latest/download/eksctl_$(uname -s)_amd64.tar.gz" | tar xz -C /tmp
$ sudo mv /tmp/eksctl /usr/local/bin

eksctlバージョン確認

$ eksctl version
  0.31.0

kubectlのインストール
※2023年9月現在、EKSの最新バージョンが1.27だったため、それに合わせます。
　EKSのバージョンとかけ離れている、それより高いバージョンのkubectlは使用できません。

curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
sudo apt-add-repository "deb http://apt.kubernetes.io/ kubernetes-xenial main"
sudo apt update
sudo apt install -y kubectl=1.27.5-00

ネットワーク・ロールの構築

KESを使用するために入れ物としてネットワークを準備しておく必要があります。
また、クラスタ、ワーカーを動かす権限としてロールの作成も行う必要があります。

以下のyaml, jsonを用いてcloudformationのコンソールからスタックを作成し、ネットワーク・ロールを作成いたします。

スタック名 EKS-Vpc
※パラメータはIPアドレスはVPCを確認し余ってるところで適宜実装してください

---
AWSTemplateFormatVersion: '2010-09-09'
Description: 'Amazon EKS Sample VPC - Public subnets only'

Parameters:
  VpcBlock:
    Type: String
    Default: 10.10.0.0/16
    Description: The CIDR range for the VPC. This should be a valid private (RFC 1918) CIDR range.
  Subnet01Block:
    Type: String
    Default: 10.10.0.0/24
    Description: CidrBlock for subnet 01 within the VPC
  Subnet02Block:
    Type: String
    Default: 10.10.1.0/24
    Description: CidrBlock for subnet 02 within the VPC
  Subnet03Block:
    Type: String
    Default: 10.10.2.0/24
    Description: CidrBlock for subnet 03 within the VPC. This is used only if the region has more than 2 AZs.

Metadata:
  AWS::CloudFormation::Interface:
    ParameterGroups:
      -
        Label:
          default: "Worker Network Configuration"
        Parameters:
          - VpcBlock
          - Subnet01Block
          - Subnet02Block
          - Subnet03Block

Conditions:
  Has2Azs:
    Fn::Or:
      - Fn::Equals:
        - {Ref: 'AWS::Region'}
        - ap-south-1
      - Fn::Equals:
        - {Ref: 'AWS::Region'}
        - ap-northeast-2
      - Fn::Equals:
        - {Ref: 'AWS::Region'}
        - ca-central-1
      - Fn::Equals:
        - {Ref: 'AWS::Region'}
        - cn-north-1
      - Fn::Equals:
        - {Ref: 'AWS::Region'}
        - sa-east-1
      - Fn::Equals:
        - {Ref: 'AWS::Region'}
        - us-west-1

  HasMoreThan2Azs:
    Fn::Not:
      - Condition: Has2Azs

Resources:
  VPC:
    Type: AWS::EC2::VPC
    Properties:
      CidrBlock:  !Ref VpcBlock
      EnableDnsSupport: true
      EnableDnsHostnames: true
      Tags:
      - Key: Name
        Value: !Sub '${AWS::StackName}-VPC'
  InternetGateway:
    Type: "AWS::EC2::InternetGateway"
  VPCGatewayAttachment:
    Type: "AWS::EC2::VPCGatewayAttachment"
    Properties:
      InternetGatewayId: !Ref InternetGateway
      VpcId: !Ref VPC
  RouteTable:
    Type: AWS::EC2::RouteTable
    Properties:
      VpcId: !Ref VPC
      Tags:
      - Key: Name
        Value: Public Subnets
      - Key: Network
        Value: Public
  Route:
    DependsOn: VPCGatewayAttachment
    Type: AWS::EC2::Route
    Properties:
      RouteTableId: !Ref RouteTable
      DestinationCidrBlock: 0.0.0.0/0
      GatewayId: !Ref InternetGateway
  Subnet01:
    Type: AWS::EC2::Subnet
    Metadata:
      Comment: Subnet 01
    Properties:
      MapPublicIpOnLaunch: true
      AvailabilityZone:
        Fn::Select:
        - '0'
        - Fn::GetAZs:
            Ref: AWS::Region
      CidrBlock:
        Ref: Subnet01Block
      VpcId:
        Ref: VPC
      Tags:
      - Key: Name
        Value: !Sub "${AWS::StackName}-Subnet01"
      - Key: kubernetes.io/role/elb
        Value: 1
  Subnet02:
    Type: AWS::EC2::Subnet
    Metadata:
      Comment: Subnet 02
    Properties:
      MapPublicIpOnLaunch: true
      AvailabilityZone:
        Fn::Select:
        - '1'
        - Fn::GetAZs:
            Ref: AWS::Region
      CidrBlock:
        Ref: Subnet02Block
      VpcId:
        Ref: VPC
      Tags:
      - Key: Name
        Value: !Sub "${AWS::StackName}-Subnet02"
      - Key: kubernetes.io/role/elb
        Value: 1
  Subnet03:
    Condition: HasMoreThan2Azs
    Type: AWS::EC2::Subnet
    Metadata:
      Comment: Subnet 03
    Properties:
      MapPublicIpOnLaunch: true
      AvailabilityZone:
        Fn::Select:
        - '2'
        - Fn::GetAZs:
            Ref: AWS::Region
      CidrBlock:
        Ref: Subnet03Block
      VpcId:
        Ref: VPC
      Tags:
      - Key: Name
        Value: !Sub "${AWS::StackName}-Subnet03"
      - Key: kubernetes.io/role/elb
        Value: 1
  Subnet01RouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      SubnetId: !Ref Subnet01
      RouteTableId: !Ref RouteTable
  Subnet02RouteTableAssociation:
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      SubnetId: !Ref Subnet02
      RouteTableId: !Ref RouteTable
  Subnet03RouteTableAssociation:
    Condition: HasMoreThan2Azs
    Type: AWS::EC2::SubnetRouteTableAssociation
    Properties:
      SubnetId: !Ref Subnet03
      RouteTableId: !Ref RouteTable
  ControlPlaneSecurityGroup:
    Type: AWS::EC2::SecurityGroup
    Properties:
      GroupDescription: Cluster communication with worker nodes
      VpcId: !Ref VPC

Outputs:
  SubnetIds:
    Description: All subnets in the VPC
    Value:
      Fn::If:
      - HasMoreThan2Azs
      - !Join [ ",", [ !Ref Subnet01, !Ref Subnet02, !Ref Subnet03 ] ]
      - !Join [ ",", [ !Ref Subnet01, !Ref Subnet02 ] ]
  SecurityGroups:
    Description: Security group for the cluster control plane communication with worker nodes
    Value: !Join [ ",", [ !Ref ControlPlaneSecurityGroup ] ]
  VpcId:
    Description: The VPC Id
    Value: !Ref VPC

スタック名 EKS-Service-Role

AWSTemplateFormatVersion: '2010-09-09'
Description: 'Amazon EKS Cluster Role'

Resources:
  eksClusterRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
        - Effect: Allow
          Principal:
            Service:
            - eks.amazonaws.com
          Action:
          - sts:AssumeRole
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/AmazonEKSClusterPolicy

Outputs:

  RoleArn:
    Description: The role that Amazon EKS will use to create AWS resources for Kubernetes clusters
    Value: !GetAtt eksClusterRole.Arn
    Export:
      Name: !Sub "${AWS::StackName}-RoleArn"

スタック名 EKS-Nodegroup-Role

AWSTemplateFormatVersion: "2010-09-09"
Description: Amazon EKS - Node Group Role

Mappings:
  ServicePrincipals:
    aws-cn:
      ec2: ec2.amazonaws.com.cn
    aws-us-gov:
      ec2: ec2.amazonaws.com
    aws:
      ec2: ec2.amazonaws.com

Resources:
  NodeInstanceRole:
    Type: "AWS::IAM::Role"
    Properties:
      AssumeRolePolicyDocument:
        Version: "2012-10-17"
        Statement:
          - Effect: Allow
            Principal:
              Service:
                - !FindInMap [ServicePrincipals, !Ref "AWS::Partition", ec2]
            Action:
              - "sts:AssumeRole"
      ManagedPolicyArns:
        - !Sub "arn:${AWS::Partition}:iam::aws:policy/AmazonEKSWorkerNodePolicy"
        - !Sub "arn:${AWS::Partition}:iam::aws:policy/AmazonEKS_CNI_Policy"
        - !Sub "arn:${AWS::Partition}:iam::aws:policy/AmazonEC2ContainerRegistryReadOnly"
      Path: /

Outputs:
  NodeInstanceRole:
    Description: The node instance role
    Value: !GetAtt NodeInstanceRole.Arn

クラスターの作成

コンソールでクラスターを作成を行いました。（10分ぐらいかかります）
設定は以下の設定で行いました。

名前：EKS-cluster
バージョン：1.27
クラスターサービスロール　EKS-Service-Roleで作成したロール
VPC、サブネット　EKS-Vpcで作成したVPC、サブネット
セキュリティグループ　EKS-Vpcで作成したセキュリティグループ
アドオン　→　デフォルト（VPC CNI, kube-proxy, CoreDNS）

kubeconfigファイルの作成
クラスターにアクセスするためのkubekonfigファイルを作成する必要があります。
クラスター作成完了後に実行します。

aws eks --region ap-northeast-1 update-kubeconfig --name EKS-cluster

接続テスト

kubectl get svc

ワーカーノードの作成

コンソール上でワーカーノードを作成します。（5分ぐらいかかります）
コンピューティングでノードグループにあるノードグループの追加を選択し作成します。
設定は以下の設定で行いました。

名前：EKS-worker-nodes
ノードIAMロール　EKS-Nodegroup-Roleで作成したロール
EC2の設定は適宜
　AMIタイプ「Amazon Linux (AL2_x86_64)
　インスタンスタイプ「t3.small」
　ディスクサイズ「10」
　最小サイズ「2」
　最大サイズ「2」
　希望サイズ「2」
サブネット　EKS-Vpcで作成したサブネット
ノードへのリモートアクセスを許可する　ON
SSHキーを選択
次からのリモートアクセスを許可　全て

これにて、KESの基本的な準備が完了いたしました。
ここから先はreact appとnginxをコンテナ化しデプロイしてロードバランサーで公開する手順になります。

React App 作成

nvm use 18.16.1
npx create-react-app test-app

appディレクトリ直下にDockerfile格納します。

Dockerfile

FROM node:18.16.1 as builder

RUN mkdir -p /usr/src/app
WORKDIR /usr/src/app

COPY ["package.json", "package-lock.json", "./"]
RUN npm install
COPY [".", "./"]
RUN npm run build

FROM nginx:alpine
WORKDIR /usr/share/nginx/html
COPY --from=builder ["/usr/src/app/build", "./"]
COPY ["nginx/default.conf", "/etc/nginx/conf.d"]
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]

appディレクトリ直下の/nginx にdefault.conf格納します。

default.conf

server {
  listen 80;
  location / {
    root /usr/share/nginx/html;
    index index.html index.htm
    try_files $uri /index.html;
  }
}

Dockerイメージ作成

※kubernetesのネームスペース、ECRのリポジトリ名をとりあえずeks-testで作成します。

Dockerビルド

docker build -t eks-test .

以下コマンドを実行し localhost:3000でアクセスできればOKです。

docker run -p 3000:80 eks-test

ECRにコンテナ格納

まずは、ECRにコンテナのリポジトリを作成します。
コンソール上でECR（Elastic Container Registry）を開き、リポジトリの作成をクリックします。
名前を「eks-test」として入力し作成します。
eks-testの詳細にある「プッシュコマンドの表示」をクリックし、そこにある「認証・イメージタグ付け・プッシュコマンド」をローカルで実行し作成したリポジトリに格納します。

□コンテナイメージのデプロイ・サービス公開

コンテナイメージのデプロイ・サービスを一元管理するために、namespaceの作成を行います。

kubectl create namespace eks-test

以下のデプロイ・サービス公開するための設定ファイルを適当なディレクトリに格納してください。

EKS-Deployment.yaml（ECRのURIを適宜書き換えること）

apiVersion: apps/v1
kind: Deployment
metadata:
  name: eks-test
spec:
  selector:
    matchLabels:
      app: eks-test
  replicas: 2
  template:
    metadata:
      labels:
        app: eks-test
    spec:
      containers:
        - name: eks-test
          image: <ECRのURI>
          imagePullPolicy: Always
          ports:
            - containerPort: 80

EKS-Service.yaml

apiVersion: v1
kind: Service
metadata:
  name: eks-test
spec:
  type: LoadBalancer
  selector:
    app: eks-test
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80

格納したディレクトレイで以下コマンドを実行します。
アプリデプロイ

kubectl apply -f EKS-Deployment.yaml -n eks-test

サービス作成

kubectl apply -f EKS-Service.yaml -n eks-test

以下で取得できるEXTERNAL-IPでアプリにアクセスすることができれば成功です。（なんだかんだ公開に二分ぐらいまちます。）

kubectl get service -n eks-test

以上で、EKSを用いてReactAppを公開する手順を終了します。

全削除

作成したリソースの削除方法です。お片付けはちゃんとしないとね。

ネームスペース削除（紐づいたノード、サービスも消える）

kubectl delete namespace eks-test

ECRリポジトリの削除

aws ecr delete-repository --repository-name eks-test --force --region ap-northeast-1

ノードグループの削除

aws eks delete-nodegroup --nodegroup-name EKS-worker-nodes --cluster-name EKS-cluster --region ap-northeast-1

クラスター削除

aws eks delete-cluster --name EKS-cluster --region ap-northeast-1

クラウドフォーメーション削除

aws cloudformation delete-stack --stack-name EKS-Vpc
aws cloudformation delete-stack --stack-name EKS-Service-Role
aws cloudformation delete-stack --stack-name EKS-Nodegroup-Role

終わりに

ここまで読んでいただきありがとうございました。
記事を書くに当たり、以下サイトを参考にさせていただきました。
また、執筆する気持ちになりましたらその時お会いしましょう。