この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
みなさん、こんにちは！
AWS事業本部の青柳＠福岡オフィスです。
このブログ記事は「Amazon EKS Advent Calendar 2019」の10日目のエントリです
re:Inventで公開された「Fargate for EKS」に合わせて、EKSのコマンドラインツール「eksctl」も version 0.11.0 で「Fargate for EKS」に対応しました。
今回は、「Fargate for EKS」に関係する部分を中心にeksctlコマンドの使い方を見ていきたいと思います。
はじめに：「eksctl」のススメ (特に初学者)
現在、EKSの環境を作成して使い始めるには、いくつかの方法があります。
- マネジメントコンソール
- AWS CLI
- eksctl
- Terraform
この中で、個人的に最も「お手軽」なのは「eksctl」だと思います。
というのも、他の方法だと「IAMロール」や「セキュリティグループ」などEKSに必要な関連リソースを事前に個別に作成する必要がありますが、eksctlを使うと自動的にこれらのリソースを作成してくれるからです。
(もちろん、これらの関連リソースがどのようなものが作成されるのかを知っておくことは重要です。機会があれば、公式ドキュメントを参照したり、eksctlで自動生成されたリソースを確認したりしてみることをお勧めします)
eksctlについては、以前に「入門ブログ」を書きましたので、併せて参考にして頂ければと思います。(Fargate for EKSに対応する前の内容です)
「eksctl」コマンドを使ったAmazon EKS構築入門 ｜ Developers.IO
準備： eksctlおよびその他ツールのインストール
まだeksctlをインストールしていない方は、以下のeksctl公式サイトの「インストール手順」を参照して、インストールしましょう。
https://eksctl.io/introduction/installation/
既にeksctlをインストールしている方は、「Fargate for EKS」に対応したバージョン (0.11.0以降) にアップデートしておいてください。
また、「AWS CLI」「kubectl」などの関連するツールも最新バージョンにしておきましょう。
参考まで、今回のブログは以下の各ツールのバージョンを前提にしています。
$ eksctl version
[i] version.Info{BuiltAt:"", GitCommit:"", GitTag:"0.11.1"}
$ aws --version
aws-cli/1.16.298 Python/3.6.7 Linux/4.4.0-18362-Microsoft botocore/1.13.34
$ kubectl version --client --short
Client Version: v1.16.3EKSクラスターを作成してPodを起動してみる (EC2/Fargate)
その1： EC2ワーカーノードのみに対応した従来のクラスターを作成する
「Fargate for EKS」について見ていく前に、まずは従来のEC2ワーカーノードのみに対応したEKSクラスターを作成してみます。
今回は、以下のようなオプションを指定して実行しました。
eksctl create cluster \
--name eks-example1 \
--nodegroup-name ng-example \
--node-type t3.large \
--nodes 2 \
--managed最低限のオプションとして「ノードグループ名」「ノードタイプ」「ノード数」を指定しています。
また、re:Inventの直前にリリースされた「Managed Node Group」に対応させるため --managed も指定しています。
(これを指定しないと、マネジメントコンソールにノードグループが表示されなくなりますので注意してください)
作成されたクラスターを確認する
EKSクラスターが作成されると、以下のようになります。
--managed を付けたことにより、作成したノードグループがマネジメントコンソールに表示されています。
kubectlでNodeの一覧を確認します。
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
ip-192-168-30-117.ap-northeast-1.compute.internal Ready <none> 8m54s v1.14.7-eks-1861c5
ip-192-168-73-252.ap-northeast-1.compute.internal Ready <none> 8m59s v1.14.7-eks-1861c5ワーカーノードが2つ作成されていることが確認できます。
Podを起動してみる
では、作成したEKSクラスター上でPodを起動してみます。
以下のマニフェストファイルを用意します。
(nginxコンテナを6つ起動するというシンプルな内容です。コンテナのポート番号などを指定していますが、今回はnginxへのアクセスは行わず、Podを起動させる目的のみで使用します)
nginx-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
selector:
matchLabels:
app: nginx
replicas: 6
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.16.1
ports:
- containerPort: 80マニフェストを使ってDeploymentを作成します。
$ kubectl apply -f nginx-deployment.yaml
deployment.apps/nginx-deployment created作成されたリソースを確認します。
$ kubectl get deployments
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 6/6 6 6 13s
$ kubectl get replicasets
NAME DESIRED CURRENT READY AGE
nginx-deployment-59777878f8 6 6 6 33s
$ kubectl get pods --output wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-deployment-59777878f8-2n4n9 1/1 Running 0 49s 192.168.70.25 ip-192-168-73-252.ap-northeast-1.compute.internal <none> <none>
nginx-deployment-59777878f8-7wc95 1/1 Running 0 49s 192.168.20.63 ip-192-168-30-117.ap-northeast-1.compute.internal <none> <none>
nginx-deployment-59777878f8-9cl8r 1/1 Running 0 49s 192.168.31.216 ip-192-168-30-117.ap-northeast-1.compute.internal <none> <none>
nginx-deployment-59777878f8-j9cvw 1/1 Running 0 49s 192.168.71.66 ip-192-168-73-252.ap-northeast-1.compute.internal <none> <none>
nginx-deployment-59777878f8-szfcc 1/1 Running 0 49s 192.168.90.80 ip-192-168-73-252.ap-northeast-1.compute.internal <none> <none>
nginx-deployment-59777878f8-x6l6f 1/1 Running 0 49s 192.168.12.59 ip-192-168-30-117.ap-northeast-1.compute.internal <none> <none>DeploymentによってReplicaSetが「レプリカ数: 6」(＝マニフェストのreplicasで指定した値) で作成され、ReplicaSetによってPodが6つ起動されました。
Podは2台のNodeに分散して配置されていることが分かります。
その2： Fargateのみに対応したクラスターを作成する
では、いよいよ「Fargate for EKS」に対応したEKSクラスターを作成してみます。
eksctlを使って「Fargate for EKS」を使い始める最も簡単な方法は、eksctl version 0.11.0 で追加された --fargate オプションを指定することです。
eksctl create cluster \
--name eks-example2 \
--fargate--fargate オプションを指定すると、「Fargate for EKS」で必要となる「Fargateプロファイル」が作成されます。
また、--fargate オプションを指定した場合は、ノードグループは作成されません。
暗黙的に --without-nodegroup が指定されていると考えて良いと思います。
作成されたクラスターを確認する
EKSクラスターが作成されると、以下のようになります。
ノードグループが作成されておらず、Fargateプロファイルが作成されていることが分かります。
--fargate オプションの指定により作成されたFargateプロファイルは以下のようになります。
Fargateプロファイルには「Pod実行ロール」「サブネット」などいくつかの要素が含まれますが、最も重要な要素は「Podセレクター」です。
Podセレクターとは、Fargate上で実行させたいPodの条件を指定するための設定です。
具体的には、KubernetesのNamespaceを指定することで、特定のNamespaceに属するPodのみがFargate上で実行されるように制御することができます。
今回作成されたFargateプロファイルには、2つの「Podセレクター」が定義されており、それぞれ「default」「kube-system」というNamespaceが指定されています。
※ default： Namespaceを明示しなかった場合にデフォルトで選択されるNamespace
※ kube-system： Kubernetesがシステムで使用するリソースを配置する際に使用されるNamespace
eksctlコマンドでFargateプロファイルの内容を確認すると以下のようになります。
$ eksctl get fargateprofile --cluster eks-example2 --name fp-default --output yaml
- name: fp-default
podExecutionRoleARN: arn:aws:iam::123456789012:role/eksctl-eks-example2-cluste-FargatePodExecutionRole-ZNKQBZ3EU0Z5
selectors:
- namespace: default
- namespace: kube-system
subnets:
- subnet-08f33de655742dcbc
- subnet-0bd0ddd636af6f0a2
- subnet-018418fe4c5f53bdeマネジメントコンソールで参照できる情報と同様に、「Pod実行ロール」「Podセレクター」「サブネット」の情報が確認できます。
Podを起動してみる
「その1」の時と同様のマニフェストを使ってDeploymentを作成します。
$ kubectl apply -f nginx-deployment.yaml
deployment.apps/nginx-deployment created作成されたリソースを確認します。
$ kubectl get deployments
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-deployment 6/6 6 6 69s
$ kubectl get replicasets
NAME DESIRED CURRENT READY AGE
nginx-deployment-59777878f8 6 6 6 88s
$ kubectl get pods --output wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx-deployment-59777878f8-2v6bs 1/1 Running 0 101s 192.168.140.199 fargate-ip-192-168-140-199.ap-northeast-1.compute.internal <none> <none>
nginx-deployment-59777878f8-65ss9 1/1 Running 0 101s 192.168.153.82 fargate-ip-192-168-153-82.ap-northeast-1.compute.internal <none> <none>
nginx-deployment-59777878f8-76n5g 1/1 Running 0 101s 192.168.152.19 fargate-ip-192-168-152-19.ap-northeast-1.compute.internal <none> <none>
nginx-deployment-59777878f8-mqlf8 1/1 Running 0 101s 192.168.131.119 fargate-ip-192-168-131-119.ap-northeast-1.compute.internal <none> <none>
nginx-deployment-59777878f8-s5sms 1/1 Running 0 101s 192.168.97.193 fargate-ip-192-168-97-193.ap-northeast-1.compute.internal <none> <none>
nginx-deployment-59777878f8-z826t 1/1 Running 0 101s 192.168.170.14 fargate-ip-192-168-170-14.ap-northeast-1.compute.internal <none> <none>「その1」の時と同様に、Deployment、ReplicaSetが作成され、Podが6つ起動されています。
Podの「Node」欄を見てみましょう。
「fargate-～」で始まる「ノード」上にPodが配置されていることになっています。
6つのノードは全て異なる名前です。
実は、これがPodの起動要求によって作成された「Fargate」であり、6つのPodを動かすために6つのFargateが作成されていることを示します。
つまり、Fargate for EKSでは、Kubernetes上において1つのFargateは1台のワーカーノードのように見える、ということになります。
(あくまで「のように見える」というだけで、EC2インスタンスベースのワーカーノードと全く同じ物が作成される訳ではありません)
では、ここで、Nodeの一覧を表示してみましょう。
$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
fargate-ip-192-168-118-124.ap-northeast-1.compute.internal Ready <none> 14m v1.14.8-eks
fargate-ip-192-168-127-142.ap-northeast-1.compute.internal Ready <none> 14m v1.14.8-eks
fargate-ip-192-168-131-119.ap-northeast-1.compute.internal Ready <none> 110s v1.14.8-eks
fargate-ip-192-168-140-199.ap-northeast-1.compute.internal Ready <none> 115s v1.14.8-eks
fargate-ip-192-168-152-19.ap-northeast-1.compute.internal Ready <none> 115s v1.14.8-eks
fargate-ip-192-168-153-82.ap-northeast-1.compute.internal Ready <none> 115s v1.14.8-eks
fargate-ip-192-168-170-14.ap-northeast-1.compute.internal Ready <none> 83s v1.14.8-eks
fargate-ip-192-168-97-193.ap-northeast-1.compute.internal Ready <none> 99s v1.14.8-eks「Fargate-～」で始まる「ノード」が8つ作成されていることが分かります。
ん？ 「8つ」？
さっき「6つのPodを動かすために6つのFargateが作成されている」と書きましたよね。
なのに「8つ」とは一体・・・？
Namespace「kube-system」に作成されるPodの動作
正体を明かすと、「2つ」余分に作成されているFargateは、「CoreDNS」というKubernetesのシステムが使用する特殊なPodを起動するために作成されたものです。
CoreDNSの詳細な説明は割愛しますが、CoreDNSのリソースがどのように作成されたのかは、Namespace「kube-system」のDeployment、ReplicaSet、Podの一覧を表示すると分かります。
$ kubectl get deployments --namespace kube-system
NAME READY UP-TO-DATE AVAILABLE AGE
coredns 2/2 2 2 102m
$ kubectl get replicasets --namespace kube-system
NAME DESIRED CURRENT READY AGE
coredns-699bb99bf8 0 0 0 102m
coredns-6d75bbbf58 2 2 2 98m
$ kubectl get pods --namespace kube-system --output wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
coredns-6d75bbbf58-8zlrg 1/1 Running 0 98m 192.168.127.142 fargate-ip-192-168-127-142.ap-northeast-1.compute.internal <none> <none>
coredns-6d75bbbf58-q2kr9 1/1 Running 0 98m 192.168.118.124 fargate-ip-192-168-118-124.ap-northeast-1.compute.internal <none> <none>Fargateプロファイルの内容を思い出してみましょう。
Podセレクターとして「default」Namespaceともう一つ「kube-system」Namespaceが条件として定義されていたと思います。
このように、Kubernetesのシステムが使用するPodもFargate上で実行させる必要があるため、「kube-system」NamespaceがPodセレクターに定義されていたのです。
Podセレクターに定義されていないNamespaceのPodを起動すると・・・？
では、ここで敢えて、Podセレクターに定義されていないNamespaceを指定して、Podの起動を試みてみます。
まず、適当に「hogehoge」という名前のNamespaceを作成します。
$ kubectl create namespace hogehoge
namespace/hogehoge createdこのNamespaceを指定してDeploymentを作成します。
(簡略化のためにマニフェストを使用せずに直接作成します)
$ kubectl create deployment nginx-hogehoge --image nginx --namespace hogehoge
deployment.apps/nginx-hogehoge createdPodが起動されたかどうか見てみましょう。
$ kubectl get deployments --namespace hogehoge
NAME READY UP-TO-DATE AVAILABLE AGE
nginx-hogehoge 0/1 1 0 4m36s
$ kubectl get replicasets --namespace hogehoge
NAME DESIRED CURRENT READY AGE
nginx-hogehoge-7b58884cf 1 1 0 4m43s
$ kubectl get pods --namespace hogehoge
NAME READY STATUS RESTARTS AGE
nginx-hogehoge-7b58884cf-6jwlt 0/1 Pending 0 5mDeploymentを作成して5分近く経過したのにもかかわらず、Podのステータスが「Pending」となっています。
何が起こっているのか、イベントを確認します。
$ kubectl get events --namespace hogehoge
LAST SEEN TYPE REASON OBJECT MESSAGE
66s Warning FailedScheduling pod/nginx-hogehoge-7b58884cf-6jwlt 0/8 nodes are available: 8 Insufficient pods.
5m13s Normal SuccessfulCreate replicaset/nginx-hogehoge-7b58884cf Created pod: nginx-hogehoge-7b58884cf-6jwlt
5m13s Normal ScalingReplicaSet deployment/nginx-hogehoge Scaled up replica set nginx-hogehoge-7b58884cf to 1Deployment、ReplicaSetは正常に作成されていますが、Podの起動において「Podの起動に十分なNodeが無い」というようなことを言われています。(ちょっと意訳入ってます？)
ともかく、Podセレクターに定義されていないNamespaceを指定してPodを起動しようとしても、Podが起動されないことが分かりました。
Fargate for EKSを利用する際は、使用するNamespaceを予めFargateプロファイルに登録しておく必要があるということですね。
おまけ： CoreDNSの起動時に起こっていること
さて、上の方で「CoreDNSを起動するために作成されるDeployment、ReplicaSet、Podの一覧」を掲載しましたが、ReplicaSetの表示内容にちょっと気になるところがありました。
$ kubectl get replicasets --namespace kube-system
NAME DESIRED CURRENT READY AGE
coredns-699bb99bf8 0 0 0 102m
coredns-6d75bbbf58 2 2 2 98m1つのDeploymentに対して2つのReplicaSetが作成されていて、しかも、一方のReplicaSetは「DESIRED」「CURRENT」「READY」が全て「0」になっています。
これは、eksctlによるEKSクラスターとFargateプロファイルの作成プロセスに理由があります。
eksctlは、まずEKSクラスター (コントロールプレーン) を作成し、その後にFargateプロファイルを作成します。
一方、CoreDNSはEKSクラスターが作成された直後に、Kubernetesのシステムによって作成されます。
このタイミングでは、まだFargateプロファイルが作成されておらず、またEC2インスタンスベースのワーカーノードも存在しないため、Deployment/ReplicaSetがPodを起動しようとしても配置先のノードが存在しない状態となります。
実際に、このタイミングでPodの一覧を表示すると、以下のような結果になります。
$ kubectl get pods --all-namespaces
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-699bb99bf8-9jm7r 0/1 Pending 0 3m42s
kube-system coredns-699bb99bf8-lct9l 0/1 Pending 0 3m42s前項の「Podセレクターに定義されていないNamespaceのPodを実行すると・・・？」の時と同じ状況になっているのが分かります。
eksctlは、Fargateプロファイルの作成が完了した後に、この「行き場が無くPodを起動できないDeployment/ReplicaSet」に対して、一度「リフレッシュ」を掛けます。
(Kubernetesの正式な用語では「rollout」と言います)
リフレッシュを掛けられたDeploymentは、Podを配置することができないReplicaSsetに見切りを付け、新たに別のReplicaSetを作成します。
そして、そのReplicaSetが、今度はFargateを使用してPodを無事起動することができた、という訳です。
ReplicaSetが2つ表示されるのは、そういうことなんですね。
(「DESIRE」が「0」になっているというのは「見切りを付けられた」ということなのです)
おわりに
eksctlを使用した「Fargate for EKS」に対応したEKSクラスターの作成を、従来の従来のEC2ワーカーノードのみに対応したEKSクラスターの場合と比較しながら行ってみました。
今回は、作成した「Fargate for EKS」なEKSクラスターの上で単純なPodの起動しか試せませんでしたが、「Service」や「Ingress」など、他のKubernetesリソースと組み合わせた場合についても試してみたいと思います。
39
