結論

AWSにデプロイすることはできた。
しかしFargateが使えない分、GKEと比べるとやや面倒¹。

概要

microservices-demoを用いて、Kubernetesのアプリケーションの検証をしたい。
GKEのクラスタを作成後、以下を実行することで実現できる。

kubectl apply -f ./release/kubernetes-manifests.yaml

これをAWSでもデプロイできるようにしたい。
※EKS Fargateにアプリケーションがデプロイされるだけで、Pod間の通信制御などは行われない

Kubernetesリソースの差分

リポジトリをクローンしてきて、kubernetes-manifests.yaml を確認する。

Ingressリソースはないため、L7ロードバランサはない。その代わり、以下のLoadBalancerを作成した際にGKEではLoadBalancer Serviceが作成される

apiVersion: v1
kind: Service
metadata:
  name: frontend-external
spec:
  type: LoadBalancer
  selector:
    app: frontend
  ports:
  - name: http
    port: 80
    targetPort: 8080

インターネットからのアクセスが可能なので、作成されるのは外部 TCP / UDP ロードバランサに該当する。

LoadBalancer サービスを作成すると、GKE により、その特性がサービスマニフェストのパラメータに依存する Google Cloud のパススルーロードバランサが構成されます。 https://cloud.google.com/kubernetes-engine/docs/concepts/service-load-balancer?hl=ja

外部 TCP / UDP ロードバランサはSSLを終端しないロードバランサ(NLBのようなもの)らしい。

パススルーロードバランサでは、クライアント接続を終端しません。ロードバランシングされたパケットは、パケットの送信元、宛先、ポート情報（該当する場合）が変更されずにバックエンド VM によって受信されます。

したがって、Internet-facingなNLBを作成して、Podにリクエストするようにすればとりあえずデプロイはできる。

AWSでtypeがLoadBalancerのServiceを作成するとCLBかNLBが作成される。この方法は推奨されていないが、一旦はこの方法を用いる。

実行

①EKSクラスタの作成

ドキュメントに従って、クラスタを作成する。

②EKS Nodeの作成

マネージド型ノードグループを作成

③yamlの修正

kubernetes-manifests.yamlを以下のように修正(service.beta.kubernetes.io/aws-load-balancer-type: nlbをアノテーションに追加)

kind: Service
metadata:
  name: frontend-external
+  annotations:
+    service.beta.kubernetes.io/aws-load-balancer-type: nlb
spec:
  type: LoadBalancer
  selector:
    app: frontend
  ports:
  - name: http
    port: 80
    targetPort: 8080

④k8sリソース作成

kubectl apply -f ./release/kubernetes-manifests.yaml

Podの作成完了

デプロイも完了

Fargateを用いようとするとAWS Load Balancer Controller add-onを使う必要があるなど、差分が大きい↩

regmarmcem’s diary

microservices-demoをAWSにデプロイするその1

結論

概要

Kubernetesリソースの差分

実行