Kubernetesがとっつきにくい原因の一つは、操作がすべてCLIベースなことなのでは…と思っていたら、ちゃんとWeb UI（ダッシュボード）なるものが存在したようなので、これをAWS環境で試しにデプロイしてみることにした。
環境準備（おうちEKSクラスターの作成まで）
今回は作業端末としてMac（M1 MacBook Air）を利用した。
- Homebrewのインストール
- eksctlのインストール
- 対象AWSアカウントのIAM認証情報をシェルの環境変数へセットする（参考）
試しに eksctl get cluster を打って結果が返って来れば準備完了。
以下のコマンドを打って検証用EKSクラスターを構築する。
eksctl create cluster \
--name お好きなクラスター名を指定 \
--region ap-northeast-1 \
--fargate
なお今回は気分でワーカーノードをEC2ではなくFargateで構成した。
デプロイ所要時間はEC2でもFargateでも変わらず20分程度。
ダッシュボードのデプロイ
手順はAWS公式チュートリアルを参考にした。
まずは以下コマンドでダッシュボードをデプロイ。
ちなみにマニフェストの中身を覗いてみると、デプロイメント2点を中心に、サービスやシークレットなど複数のリソース定義が含まれている模様。
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.5/aio/deploy/recommended.yaml
リソースがこんだけ作成された。
namespace/kubernetes-dashboard created
serviceaccount/kubernetes-dashboard created
service/kubernetes-dashboard created
secret/kubernetes-dashboard-certs created
secret/kubernetes-dashboard-csrf created
secret/kubernetes-dashboard-key-holder created
configmap/kubernetes-dashboard-settings created
role.rbac.authorization.k8s.io/kubernetes-dashboard created
clusterrole.rbac.authorization.k8s.io/kubernetes-dashboard created
rolebinding.rbac.authorization.k8s.io/kubernetes-dashboard created
clusterrolebinding.rbac.authorization.k8s.io/kubernetes-dashboard created
deployment.apps/kubernetes-dashboard created
service/dashboard-metrics-scraper created
deployment.apps/dashboard-metrics-scraper created
試しに kubectl get pod しても default ネームスペースにPodは増えていないが、 kubectl get namespace するとダッシュボード用のネームスペースが増えていることが分かる。
ネームスペース指定で覗いてみると…
% kubectl get pod --namespace kubernetes-dashboard
NAME READY STATUS RESTARTS AGE
dashboard-metrics-scraper-856586f554-sdsmf 0/1 Pending 0 3m8s
kubernetes-dashboard-7979bc45d5-h4cjt 0/1 Pending 0 3m8s
Podが2つ動いているが、Pendingになっている。
いいのかな？ノードのリソース足りてないのかな、と少し心配になるがとりあえず続行。
アクセス許可の追加（eks-admin）
とりあえず手順に沿ってサービスアカウントとクラスターロールバインディングを作成する。
以下のマニフェストをローカルで作成し保存。
apiVersion: v1
kind: ServiceAccount
metadata:
name: eks-admin
namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
name: eks-admin
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- kind: ServiceAccount
name: eks-admin
namespace: kube-system
上記をapplyする。
kubectl apply -f eks-admin.yaml
ダッシュボードに接続
上記で作成した eks-admin サービスアカウントの認証トークンを取得し、それを利用してダッシュボードにアクセスするようだ。
まずは認証トークンを取得する。
kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep eks-admin | awk '{print $1}')
次にプロキシーを立ち上げる。
kubectl proxy
そしてブラウザで下記リンクを起動。
すると…JSONっぽいテキストが返却された。見ると503っぽい。
やっぱりPod上がってないのおかしいんじゃね？と思いつつトラシュー開始。
ダッシュボードが起動しない！トラシュー開始
とりあえずPodの状態をdescribeしてみよう。
まずPodの一覧を取得。
% kubectl get pod --namespace kubernetes-dashboard
NAME READY STATUS RESTARTS AGE
dashboard-metrics-scraper-856586f554-sdsmf 0/1 Pending 0 30m
kubernetes-dashboard-7979bc45d5-h4cjt 0/1 Pending 0 30m
メインっぽいPodの名前をコピペし、describeする。
% kubectl describe pod kubernetes-dashboard-7979bc45d5-h4cjt --namespace kubernetes-dashboard
Name: kubernetes-dashboard-7979bc45d5-h4cjt
Namespace: kubernetes-dashboard
（中略）
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 35s (x32 over 31m) default-scheduler 0/2 nodes are available: 2 node(s) had taint {eks.amazonaws.com/compute-type: fargate}, that the pod didn't tolerate.
なるほど！
「Fargateへのtaintがあるから、耐えられずFailedしてるよ！」ということらしい。
ググるとtaintとはPodの稼働ノードをブラックリスト指定する属性（affinityの逆？）で、おそらくダッシュボードPodは何故かFargateノード上で起動すんなよって設定になっていることが考えられる。なんでだろう。。
とりあえずクラスターをEC2で再デプロイするのが楽そうだけど、また20分待つのがイヤなので別の方法をトライ。
Dashboardをデプロイした際のYAMLを全文検索してみると、 taint はヒットしないが toleration にヒットする箇所が2件。
いずれもご丁寧に「適宜コメントアウトせよ」とコメントされている。
気を取り直して、まずはデプロイしたマニフェストを指定してオブジェクト削除。
kubectl delete -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.5/aio/deploy/recommended.yaml
お掃除完了したら、当該YAMLからtaint 2箇所を削ったマニフェストでDashboardを再デプロイ。
kubectl apply -f dashboard.yaml
そしてPodの状態確認…してみるも、またも状況変わらず。。
# Pod名を取得
% kubectl get pod --namespace kubernetes-dashboard
NAME READY STATUS RESTARTS AGE
dashboard-metrics-scraper-74646b48b7-lrq2b 0/1 Pending 0 18s
kubernetes-dashboard-78dcf65b8f-42rw6 0/1 Pending 0 18s
# Pod詳細を取得
% kubectl describe pod kubernetes-dashboard-78dcf65b8f-42rw6 --namespace kubernetes-dashboard
Name: kubernetes-dashboard-78dcf65b8f-42rw6
Namespace: kubernetes-dashboard
（中略）
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Warning FailedScheduling 49s (x2 over 51s) default-scheduler 0/2 nodes are available: 2 node(s) had taint {eks.amazonaws.com/compute-type: fargate}, that the pod didn't tolerate.
Dashboardのマニフェスト以外のどこかでtaintが設定されているんだろうか？
面倒だがEC2実行モードでEKSクラスターを再作成してみることにする。。
リトライ：ダッシュボードに接続
FargateをやめてEC2で新規EKSクラスター再作成しリトライ。
今度はDashboard関連PodがRunningなことを確認。
% kubectl get pod --namespace kubernetes-dashboard
NAME READY STATUS RESTARTS AGE
dashboard-metrics-scraper-856586f554-c48k2 1/1 Running 0 16s
kubernetes-dashboard-7979bc45d5-gh46h 1/1 Running 0 16s
そして eks-admin 関連リソースもデプロイ完了。
メッセージによるとClusterRoleBindingがベータ版のリソースを使用していたらしく、EKS v1.22以降はサポートされないよと脅される。今回はまだv1.21なのでセーフ。
そして認証トークン取得後、proxyを立ち上げダッシュボードURLにHTTPアクセスすると…
成功！
トークンをコピペし認証すると…
ダッシュボード表示成功！
ダッシュボードを触ってみる
試しにPodをデプロイしてみる。
NGINXイメージを複数Pod稼働させるdeploymentマニフェストを作成しデプロイ。
kubectl apply -f deployment.yaml
そして再度ダッシュボードにアクセスすると、ちゃんとデプロイメントが反映されている。
GUIで状態が可視化されるのはいいが、ちゃんと設定変更が行えるのか試してみる。
ためしにデプロイメント「Triple-nginx」の … ボタンから「編集」してみると…
YAMLを直接編集できるモーダルウィンドウが表示された。
ここで内容を更新すると、再度applyが走るようだ。
あとはデプロイメントに「スケール」というオプションもあったので押してみると
レプリカ数をGUIから調節できる模様。
CLIコマンドも併記されていて分かりやすい。
さらにPodにも … オプションがあるので覗いてみると…
「ログ」や「実行」なるコマンドが。
まず「実行」を試してみる
Podにシェルで接続してくれるようだ。kubectl exec を指しているものと思われる。
ウィンドウ上の「nginx」がプルダウンになっているのは、恐らくPod内に複数コンテナを含む場合に切り替えが可能なものと想像。
あとはもう一つの「ログ」ボタンを押してみると…
「実行」機能と同様、CLIモードでPodのログらしきものが表示された。
右上にダウンロードボタンもあり、ログの取得も簡単にできそう。これは便利。
まとめ
ダッシュボードは見やすく編集操作もでき、デプロイも簡単（Fargateでハマらなければ）だったので、商用環境でも使えると便利なように思える。
Dashboard関連オブジェクトがどのくらいノードのリソースを食うかの確認は必要そうなのと、アクセス提供＆制御の設計は少し工夫がいりそうだが、メインで利用するモニタリングツールによってはこいつの利用を検討してみたい。