今回、作成するもの
- EKSクラスター
- 前回作成したVPCの各値を利用してEKSクラスターを作成していきます。
イメージしている構成
- 赤枠で囲んだEC2、2台で構成するEKSを作っていきます。
構築方法
- 踏み台サーバから
eksctlを使って以下のyamlを適用します。- create-eks-cluster.yaml
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
metadata:
name: ver-Mattermost-eks
region: ap-northeast-1
vpc:
id: "vpc-xxxxxxxxxxxxxx" # 前段階で作成したVPCのIDを入力
cidr: "10.0.0.0/16"
clusterEndpoints:
privateAccess: true
publicAccess: true
publicAccessCIDRs:
- "xx.xx.xx.xx/32" # ここは踏み台サーバのグローバルIPを指定する(と良いと思われる、今回はそれをしなくて後で設定追加をした)
subnets:
public:
ap-northeast-1a:
id: "subnet-xxxxxxxxxxxxxx" # 前段階で作成したsubnetのIDを入力
cidr: "10.0.10.0/24"
ap-northeast-1c:
id: "subnet-xxxxxxxxxxxxxx"
cidr: "10.0.11.0/24"
ap-northeast-1d:
id: "subnet-xxxxxxxxxxxxxx"
cidr: "10.0.12.0/24"
private:
ap-northeast-1a:
id: "subnet-xxxxxxxxxxxxxx"
cidr: "10.0.20.0/24"
ap-northeast-1c:
id: "subnet-xxxxxxxxxxxxxx"
cidr: "10.0.21.0/24"
ap-northeast-1d:
id: "subnet-xxxxxxxxxxxxxx"
cidr: "10.0.22.0/24"
nodeGroups:
- name: Mattermost-eks-node
instanceType: t3.medium
volumeSize: 50
desiredCapacity: 2
privateNetworking: true # ここをtrueにするとプライベートサブネットにEKSクラスターが作成される
minSize: 2
maxSize: 4
iam:
withAddonPolicies:
autoScaler: true
-
これでプライベートサブネットにEC2が2台作られてEKSクラスターとして設定されます。
-
今回の
create-eks-cluster.yamlではvpcとnodegroupを同時に定義していますが、nodegroupは随時更新がかかる可能性が高いので別のテンプレートにすることも考慮した方がいいかもしれません。 -
あとはEC2にsshするためのキーペアの設定も今回はしていないですが、その辺りも考慮が必要な点かと思っています。
確認：作成したEKSクラスターに接続できるか
- では確認ということで、踏み台サーバにアクセスして、
kubectlが利用できるかを確認してみます。- ここで、つまづきました、、、kubectlコマンドを打っても反応がないのです、、、
$ kubectl get svc
Unable to connect to the server: dial tcp 10.0.20.12:443: i/o timeout
- 上記の現象は
create-eks-cluster.yamlの中でもコメントに書いたのですが、publicAccessCIDRsの値を踏み台サーバのグローバルIPに指定しなかったことから来る通信不通の状況かと思われます。 - ということで、手作業でセキュリティグループに踏み台サーバからのアクセスを許可する設定を入れて解決しました。
- 具体的には以下にまとめたセキュリティグループの
項番：4に、踏み台サーバのセキュリティグループからのhttpsのインバウンド通信を許可することで対応を行いました。
- 具体的には以下にまとめたセキュリティグループの
補足：eksctlで作られたセキュリティグループ
| 項番 | セキュリティグループ名 | 説明 |
|---|---|---|
| 1 | eks-cluster-sg-ver-Mattermost-eks-xxxxxxx | 管理されていないノードがコントロールプレーン（全ポート）と通信できるようにする |
| 2 | eksctl-ver-Mattermost-eks-cluster/ClusterSharedNodeSecurityGroup | 管理ノードと非管理ノードが相互に通信できるようにする（すべてのポート) ノード同士の通信を許可する（すべてのポート） |
| 3 | eksctl-ver-Mattermost-eks-nodegroup-Mattermost-eks-node/SG | ワーカーノードがコントロールプレーン（kubeletとワークロードのTCPポート）と通信できるようにします。ワーカーノードがコントロールプレーンと通信することを許可します(HTTPSポートを使用するワークロード、拡張APIサーバで一般的に使用されます) |
| 4 | eksctl-ver-Mattermost-eks-cluster/ControlPlaneSecurityGroup | コントロールプレーンがワーカーノードからAPIリクエストを受信できるようにします。 |
-
このセキュリティグループの1つずつがどことどこを接続しているかを考察してみましたが、まだ
項番：1がどこの接続が理解できていません。(誰か教えてください
)- 現時点で分かる範囲で言うと、以下のような接続になっているのかなと考えています。
- 現時点で分かる範囲で言うと、以下のような接続になっているのかなと考えています。
-
解決後のアクセス
- kubectlでsvcが見えました。
$ kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 172.20.0.1 <none> 443/TCP 6d2h
Nodeの確認
- つづけてNodeの確認をしようとすると、次はNodeが見えません。
$ kubectl get nodes
No resources found.
- 実はここに行き着くまでパブリックサブネットにワーカーノードを建てていた時期があり、そのときはこの時点で問題なくNodeが見えていました。
- プライベートサブネットにNodeを配置したことによってなにか変わった？でも解決方法はサブネットとは関係のないIAM関連の設定でした。
- 解決方法
- AWS authenticator configuration mapファイルをダウンロードし、そのファイル内に
NodeInstanceRoleを入れ込みます。
- AWS authenticator configuration mapファイルをダウンロードし、そのファイル内に
$ curl -O https://amazon-eks.s3-us-west-2.amazonaws.com/1.10.3/2018-06-05/aws-auth-cm.yaml
apiVersion: v1
kind: ConfigMap
metadata:
name: aws-auth
namespace: kube-system
data:
mapRoles: |
- rolearn: ★NodeInstanceRole★
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:bootstrappers
- system:nodes
kubectlでConfigMapを適用します。
$ kubectl apply -f aws-auth-cm.yaml
configmap "aws-auth" created
-
参考：AWS EKSをGitLabデプロイ環境として使う - Qiita
-
NodeInstanceRoleの取得方法は上記参考URLに記載されています
-
-
解決後のアクセス
- kubectlでnodeが見えました。
$ kubectl get node
NAME STATUS ROLES AGE VERSION
ip-10-0-21-171.ap-northeast-1.compute.internal Ready <none> 6d1h v1.16.13-eks-ec92d4
ip-10-0-22-50.ap-northeast-1.compute.internal Ready <none> 6d1h v1.16.13-eks-ec92d4
まとめ
- ということでようやくEKSクラスターが作成できました。ここからEKSクラスター上にMattermostを展開していくのですが、いきなり展開ではなく、
前準備をしていこうと思います。