KubernetesってCLIだからとっつきにくい？GUIあればいいのに → あった

Kubernetesがとっつきにくい原因の一つは、操作がすべてCLIベースなことなのでは…と思っていたら、ちゃんと[Web UI（ダッシュボード）](https://kubernetes.io/ja/docs/tasks/access-application-cluster/web-ui-dashboard/)なるものが存在したようなので、これをAWS環境で試しにデプロイしてみることにした。


# 環境準備（おうちEKSクラスターの作成まで）
今回は作業端末としてMac（M1 MacBook Air）を利用した。

- Homebrewのインストール
- eksctlのインストール
- 対象AWSアカウントのIAM認証情報をシェルの環境変数へセットする（[参考](https://docs.aws.amazon.com/ja_jp/cli/latest/userguide/cli-configure-envvars.html)）

試しに `eksctl get cluster` を打って結果が返って来れば準備完了。
以下のコマンドを打って検証用EKSクラスターを構築する。

```zsh
eksctl create cluster \
--name お好きなクラスター名を指定 \
--region ap-northeast-1 \
--fargate
```

なお今回は気分でワーカーノードをEC2ではなくFargateで構成した。
デプロイ所要時間はEC2でもFargateでも変わらず20分程度。


# ダッシュボードのデプロイ
手順はAWS公式チュートリアルを参考にした。

https://docs.aws.amazon.com/ja_jp/eks/latest/userguide/dashboard-tutorial.html

まずは以下コマンドでダッシュボードをデプロイ。
ちなみにマニフェストの中身を覗いてみると、デプロイメント2点を中心に、サービスやシークレットなど複数のリソース定義が含まれている模様。

```zsh
kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.5/aio/deploy/recommended.yaml
```

リソースがこんだけ作成された。

```zsh
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` するとダッシュボード用のネームスペースが増えていることが分かる。

ネームスペース指定で覗いてみると…

```zsh
% 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）
とりあえず手順に沿ってサービスアカウントとクラスターロールバインディングを作成する。
以下のマニフェストをローカルで作成し保存。

```zsh:eks-admin.yaml
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する。

```zsh
kubectl apply -f eks-admin.yaml
```

# ダッシュボードに接続
上記で作成した `eks-admin` サービスアカウントの認証トークンを取得し、それを利用してダッシュボードにアクセスするようだ。
まずは認証トークンを取得する。

```zsh
kubectl -n kube-system describe secret $(kubectl -n kube-system get secret | grep eks-admin | awk '{print $1}')
```

次にプロキシーを立ち上げる。

```zsh
kubectl proxy
```

そしてブラウザで下記リンクを起動。

http://localhost:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy/#!/login

すると…JSONっぽいテキストが返却された。見ると503っぽい。
やっぱりPod上がってないのおかしいんじゃね？と思いつつトラシュー開始。
![スクリーンショット 2022-02-06 17.06.57.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1633856/2b5b0529-ac10-4092-4b94-834ab3aa765a.png)


# ダッシュボードが起動しない！トラシュー開始
とりあえずPodの状態をdescribeしてみよう。
まずPodの一覧を取得。

```zsh
% 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する。

```zsh
% 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件。
いずれもご丁寧に「適宜コメントアウトせよ」とコメントされている。

気を取り直して、まずはデプロイしたマニフェストを指定してオブジェクト削除。

```zsh
kubectl delete -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.5/aio/deploy/recommended.yaml
```

お掃除完了したら、当該YAMLからtaint 2箇所を削ったマニフェストでDashboardを再デプロイ。

```zsh
kubectl apply -f dashboard.yaml
```

そしてPodの状態確認…してみるも、またも状況変わらず。。

```zsh
# 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なことを確認。

```zsh
% 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アクセスすると…
![スクリーンショット 2022-02-06 19.45.46.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1633856/182bacb5-8e21-b5fb-af7d-804f86d4c895.png)

成功！
トークンをコピペし認証すると…
![スクリーンショット 2022-02-06 19.48.13.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1633856/69de3102-9f3c-461d-7bdc-7765edee0851.png)

ダッシュボード表示成功！


# ダッシュボードを触ってみる
試しにPodをデプロイしてみる。
NGINXイメージを複数Pod稼働させるdeploymentマニフェストを作成しデプロイ。

```zsh
kubectl apply -f deployment.yaml
```

そして再度ダッシュボードにアクセスすると、ちゃんとデプロイメントが反映されている。
![スクリーンショット 2022-02-06 19.55.15.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1633856/d932b583-d25b-ce2e-5fa0-b49c98a0d2e0.png)

GUIで状態が可視化されるのはいいが、ちゃんと設定変更が行えるのか試してみる。
ためしにデプロイメント「Triple-nginx」の `…` ボタンから「編集」してみると…
![スクリーンショット 2022-02-06 19.57.41.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1633856/b9cdb788-c171-c73f-4a62-802d69df5237.png)

YAMLを直接編集できるモーダルウィンドウが表示された。
ここで内容を更新すると、再度applyが走るようだ。

あとはデプロイメントに「スケール」というオプションもあったので押してみると
![スクリーンショット 2022-02-06 19.59.47.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1633856/969fe826-83da-12ae-9165-9d874f42fb7c.png)

レプリカ数をGUIから調節できる模様。
CLIコマンドも併記されていて分かりやすい。

さらにPodにも `…` オプションがあるので覗いてみると…
![スクリーンショット 2022-02-06 20.02.26.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1633856/f374217f-3df7-e62b-2de7-77ec4bb25593.png)

「ログ」や「実行」なるコマンドが。
まず「実行」を試してみる
![スクリーンショット 2022-02-06 20.03.06.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1633856/c7c367f6-1f45-7c40-70d2-0f8e1a09d6fe.png)

Podにシェルで接続してくれるようだ。`kubectl exec` を指しているものと思われる。
ウィンドウ上の「nginx」がプルダウンになっているのは、恐らくPod内に複数コンテナを含む場合に切り替えが可能なものと想像。

あとはもう一つの「ログ」ボタンを押してみると…
![スクリーンショット 2022-02-06 20.05.41.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/1633856/1acd7e5f-7090-d14d-c0ca-73c296ebcee2.png)

「実行」機能と同様、CLIモードでPodのログらしきものが表示された。
右上にダウンロードボタンもあり、ログの取得も簡単にできそう。これは便利。


# まとめ
ダッシュボードは見やすく編集操作もでき、デプロイも簡単（Fargateでハマらなければ）だったので、商用環境でも使えると便利なように思える。
Dashboard関連オブジェクトがどのくらいノードのリソースを食うかの確認は必要そうなのと、アクセス提供＆制御の設計は少し工夫がいりそうだが、メインで利用するモニタリングツールによってはこいつの利用を検討してみたい。