AWS EKSを使ってみよう Part1~cloudshellで接続してArgo CDをデプロイした

aws

AWS EKSを使ってみようのコーナーです。EKSはオンプレミスのk8sと違ってコントロールプレーンをAWSが管理してくれるのであとは自分が好きなのをデプロイすればOK的なサービスです。AWSの他のサービスとの連携もスムーズにいくらしいです。今回はcloudshellでkubectlを使いながら動作確認とArgo CDのデプロイでもしようと思います。

AWS EKSの作成方法

AWS EKSのページからクラスターを作成ボタンを押すとこのような画面になるので、IAMロールを右の推奨ロールを作成から作成して適用させます。VPCやサブネットはすでにあるもので十分だと思うのでそのままクラスターを作成します。

ちなみにクイック設定(EKSオートモード)はワーカーノードの設定などを自動でやってくれる優れものだそうで、お試しにはこれで十分だと思います。もし詳細な設計があるクラスターを作成する際にはオートモードは切って作成したほうが良いと思います。

無事にクラスターが作成できました。

EKSクラスターに接続

cloudshellにはデフォルトでkubectlがインストールされているようです。

お試しでkubectl get pods -Aしてみます。

[cloudshell-user ~]$ kubectl get pods -A
Unable to connect to the server: dial tcp: lookup D140E6C9FC9686111701807926B0F86A.gr7.ap-southeast-2.eks.amazonaws.com on 10.0.0.2:53: no such host

クラスターが認識されていないようですね

認識してもらうためにcloudshellで以下コマンドを入力します。.kube/configの値を生成してくれるコマンドらしいです。

aws eks update-kubeconfig --region <リージョン名> --name <クラスター名>

実行例
[cloudshell-user ~]$ aws eks update-kubeconfig --region ap-southeast-2 --name thoughtful-jazz-mongoose
Added new context arn:aws:eks:ap-southeast-2:571600863668:cluster/thoughtful-jazz-mongoose to /home/cloudshell-user/.kube/config

こんな感じになれば成功なのでもう一度get podsを打ってみましょう

[cloudshell-user@ip-10-134-41-216 ~]$ kubectl get pods -A
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system metrics-server-77449dbfc5-kq5mg 1/1 Running 0 79m
kube-system metrics-server-77449dbfc5-shbg9 1/1 Running 0 79m

無事につながりました

EKSクラスターを確認

そもそもEKSクラスターがどんな感じなのか知らないのでちょっと見ていきます

[cloudshell-user ~]$ kubectl get nodes
NAME STATUS ROLES AGE VERSION
i-06447e8962d3e3e8f Ready <none> 80m v1.31.4-eks-0f56d01
i-0dec0f19fffb722cd Ready <none> 80m v1.31.4-eks-0f56d01

nodeは二つで、コントロールプレーンは見えないのでワーカーノードが2つある構成になっています。

ノードグループを作ってノードを足したり減らしたりもできるようですが、EKSオートモードで作成しているので、ノードのリソース次第でノードが増えたり減ったりするそうです。

続いてコントロールプレーンの確認です

[cloudshell-user ~]$ kubectl cluster-info
Kubernetes control plane is running at https://*****************************.***.ap-southeast-2.eks.amazonaws.com

まあこんなところで次に進みます。

Argo CDのデプロイ

kubectl create namespace argocd

kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/stable/manifests/install.yaml

これでargo cdがデプロイされます

kubectl patch svc argocd-server -n argocd -p '{"spec": {"type": "LoadBalancer"}}'

外部公開できるようにサービスタイプをロードバランサーに変更します。

EKSではロードバランサーにするとClassic Load Balancerが自動的に作成されて外部公開を自動でしてくれます。便利だなあ

kubectl get svc argocd-server -n argocd

[cloudshell-user ~]$ kubectl get svc argocd-server -n argocd

*****************************************.ap-southeast-2.elb.amazonaws.com

EXTERNAL-IPのところに上のようなelbのURLが出てきたら成功です。そのURLからArgo CDにアクセスができます。(数分かかると思います)

Argo CDの初期パスワードを取得しておきます

kubectl -n argocd get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d; echo

これでパスワードが表示されます

パスワードをコピーしたらadmin/コピーしたパスワードでサインインします。

うまくいきましたね

おまけ: loadbalancerについて

EKS(Amazon Elastic Kubernetes Service)を含むクラウドマネージドなKubernetes環境では、
Serviceをtype: LoadBalancerに指定すると、自動的にクラウドプロバイダー(この場合はAWS)が以下のことを行います。

  1. ロードバランサー(ELB)を自動作成
  2. 作成したロードバランサーに対して外部からアクセス可能なIP(またはDNS)を割り当て
  3. KubernetesのServiceと作成したロードバランサーを連携させ、自動で通信をルーティング

つまり、type: LoadBalancerのServiceは、クラウドプロバイダー(AWS)が提供するロードバランサーの仕組みを自動的に利用する仕掛けなのです。

じゃあオンプレミスのk8sクラスターでは?

$ kubectl get svc my-service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S)
my-service LoadBalancer 10.97.100.123 <pending> 80:30000/TCP

こうなるっぽい

なので、MetalLBなどをクラスターにデプロイして以下な感じで設定してloadbalancerにすればIPをつけてあげられる感じにする

##参考例
# metallb-ip-pool.yaml
apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
name: default-address-pool
namespace: metallb-system
spec:
addresses:
- 192.168.1.240-192.168.1.250

# metallb-l2-advertisement.yaml
apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
name: l2-advertisement
namespace: metallb-system

IPは基本プライベートIPなので外部からつながるようにしてあげる必要はあります

たぶんnginxかHAProxyでリバースプロキシがいいと思います

インターネット → [外部リバースプロキシ] → Kubernetes ServiceのIP(MetalLB払い出し)

設定例(Nginxでのリバースプロキシ)

外部に専用のVMやサーバを用意して、Nginxをインストールします。

例:

  • MetalLB IP:192.168.1.240(クラスター内のService)
  • 外部サーバのIP:203.0.113.10(外部公開IP)
Nginxの設定例
nginxコピーする編集するserver {
    listen 80;
    server_name your-public-domain.com;

    location / {
        proxy_pass http://192.168.1.240:80/;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
    }
}

メリット

  • SSL終端やロードバランシング、ホスト名ベースのルーティングも可能。
  • KubernetesクラスターのプライベートIPは外部に直接晒さず、安全性も高い。
  • ドメイン名ベースの運用が簡単。

まあ今後AWSしか触らないと思うのですが、一応知識としてオンプレミスのことも知っておこうと思いました

EKS面白いのでちょびちょび課金しながらいろいろ試したいと思います。

タイトルとURLをコピーしました