kun432's blog

Alexaなどスマートスピーカーの話題中心に、Voiceflowの日本語情報を発信してます。たまにAWSやkubernetesなど。

〜スマートスピーカーやVoiceflowの記事は右メニューのカテゴリからどうぞ。〜

eksctlで作成されるいろいろ

eksctl、かんたんでいいんですが、VPC周りのリソースとは分けたいし、できるだけ宣言的にやりたいんですよね。で、Terraformと組み合わせようと思ってるんですが、やり方は色々。

  • Terrafromで全部書く。これだけでもやり方いろいろ。
    • aws-eks-module
    • terraform-provider-eksctlとか。
  • Terraformでeksctl用のmanifestを出力する

でずっと詰まってます・・・ということでeksctlがやることを読み解こうというメモ。満足にTerraformもeksctlもまだまだ理解できてないけどね!

前提条件

  • VPC周り(subnetとかxgwとかroutetable)はTerraformで作成済みとします。ただし、eksクラスタの挙動に関連するもの(security groupとかxlbとか。あとIAMロール周り)はとりあえずノータッチ。eksctlだとこういう感じのコマンドになるかなと思ってます。
$ eksctl create cluster \
--name eks-test \
--vpc-public-subnets $PUBSUBNET1,$PUBSUBNET2  \
--vpc-private-subnets $PRVSUBNET1,$PRVSUBNET2 \
--region ap-northeast-1 \
--version 1.17 \
--nodegroup-name eks-nodegroup \
--node-private-networking \
--ssh-access \
--node-type t2.small \
--nodes 2 \
--nodes-min 2 \
--nodes-max 5 \
--ssh-public-key=xxx_key

manifestだとこういう感じかな。

apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
  name: eks-test
  region: ap-northeast-1
  version: "1.17"

vpc:
  id: "vpc-0dd338ecf29863c55"
  cidr: "10.0.0.0/16"
  subnets:
    private:
      ap-northeast-1c:
        id: "subnet-aaaaaaaaaaaaaaaa"
        cidr: "10.0.0.0/24"
      ap-northeast-1d:
        id: "subnet-bbbbbbbbbbbbbbbb"
        cidr: "10.0.1.0/24"
    public:
      ap-northeast-1c:
        id: "subnet-cccccccccccccccc"
        cidr: "10.0.2.0/24"
      ap-northeast-1d:
        id: "subnet-dddddddddddddddd"
        cidr: "10.0.3.0/24"

managedNodeGroups:
  - name: eks-ng-blue
    instanceType: t2.small
    desiredCapacity: 2
    minSize: 2
    maxSize: 5
    privateNetworking: true
    ssh:
      publicKeyName: xxx_key
      allow: true
    labels: {role: worker}
    tags:
      nodegroup-role: worker

ちなみにサブネットはpublic/privateで、node groupはprivateのみ、publicはxlb専用というふうに考えてます。

IAMロール

eksctlで作成されるIAMロールは以下の2つ。

  • cluster-ServiceRole
  • nodegroup-ek-NodeInstanceRole

以下を参考に見ていきます。

dev.classmethod.jp

cluster-ServiceRole

KubernetesクラスタのコントロールプレーンがAWSリソースを操作するためのポリシー、具体的には、EC2のオートスケーリングやELBの操作を行うためのもののようです。以下のようなポリシーが設定されていて、いかにもっぽいですね。

  • AmazonEKSClusterPolicy
  • AmazonEKSVPCResourceController

あとはcloudwatchにメトリクスをputしたり、ec2からIGWとかEIPを確認できるような権限が設定されているようです。

  • cluster-PolicyCloudWatchMetrics
  • cluster-PolicyELBPermissions

nodegroup-ek-NodeInstanceRole

こちらはworker nodeから、EC2の情報を参照したり、ENI周りの操作を行ったり、ECRにアクセスしたりするための権限です。worker ndoeにも紐付いてました。

  • AmazonEKSWorkerNodePolicy
  • AmazonEC2ContainerRegistryReadOnly
  • AmazonEKS_CNI_Policy

セキュリティグループ

eksctlで作成されるsecurity groupは以下の4つ。

  • eks-cluster-sg-xxxxx
  • eksctl-xxxxx-cluster/ClusterSharedNodeSecurityGroup
  • eksctl-xxxxx-cluster/ControlPlaneSecurityGroup
  • eksctl-xxxxx-nodegroup-eks-ng-blue/SSH

eks-cluster-sg-xxxxx

同じセキュリティグループ内、および、ClusterSharedNodeSecurityGroupからの通信をすべて許可してありました。つまりクラスタ内通信を全許可しているようです。 worker nodeのec2にアタッチされていました。

ClusterSharedNodeSecurityGroup

同じセキュリティグループ内、および、eks-cluster-sg-xxxxxからの通信をすべて許可してありました。

ControlPlaneSecurityGroup

コントロールプレーン向けのセキュリティグループのようです。特に設定はありませんでした。 masterはどうやって確認するんでしょうね。。。。

eksctl-xxxxx-nodegroup-eks-nodegroup-remoteAccess

VPC内のどこからworker nodeにsshできるようにしてありました。--ssh-accessがこれに当たるのだろうと思います。 worker nodeのec2にアタッチされていました。

ENIについて

ClusterSharedNodeSecurityGroupとかControlPlaneSecurityGroupは、どのEC2インスタンスにもアタッチされていなかったのですが、別のENIにアタッチされていました。worker nodeの別のENIなのかなと思ったんですが、まだ確認できてません。

まとめ

やっぱり難しいですね・・・・もう少し調査してみたいと思います。

まだ調査の途中ですが、以下のサイトがとても参考になりました。ありがとうございます。