はじめに
Ansibleを使ってkubernetes環境を構築できると知ったので、試してみました。
稼動環境
- Ansible 2.5
- APU1 (PC Engines社製) 2GB 120GB
- APU1 (PC Engines社製) 2GB 120GB
- APU2 (PC Engines社製) 4GB 128GB
- APU2 (PC Engines社製) 4GB 64GB
ネットワークは、192.168.1.0/24 のプライベートネットワークを使用しています。
Kubesprayのデプロイ
Ansibleの環境は、他の記事にも使用しているUbuntu 16.04上にオフィシャルのパッケージをインストールしている環境をそのまま使いました。
kubesprayはgithubからmasterブランチを、2018/4/18にgit cloneし、そのまま使用しています。
$ git clone https://github.com/kubernetes-incubator/kubespray.git
ドキュメントに従って、inventory/sampleのコピーを準備し、IPアドレスを書き換えるなどし、playbookを実行しました。
Dashboardへのアクセスについて
ドキュメントでは、$ kubectl proxy を実行することで、ローカルマシンから接続するように書かれています。
Ansibleを実行する時に、kubectl_localhost 変数をtrueにしていなかったので、kubectlはローカルマシンにありません。
そのためsshを利用して、マスターノードにローカルポートを転送しています。
$ ssh -L 8080:localhost:8080 node1
この後、http://localhost:8080/ui からDashboardに接続しています。
6443ポートに接続する時には、https://node1:6443/ui からでも、アクセスは可能でした。
Dashboardに接続した後…
ドキュメントは、kubesprayのデプロイについては記述されていますが、その次に何をするのかについては、記述がみつけられませんでした。
各自の利用方法に応じて、kubectl中心に利用するなり、dashboardを利用するなり、するという事なのだと思います。
単純に6443ポートを通じてアクセスした際には、Tokenの入力をスキップしてDashbaordを表示しましたが、下記のkubecloud.ioの記事中の画像にあるようなエラーが表示されていました。
この他にWebブラウザ(Firefox)の言語設定から日本語・英語を削除して、英語/USの設定のみに変更しました。
ここで理解したのは、Tokenの入力をスキップすることはできないという点と、serviceaccountの作成か、デフォルトのTokenを入力する必要があるという点です。
kubecloud.ioの記事に従って、defaultのnamespaceを作成し、dashboardアカウントを作成しています。
$ kubectl create serviceaccount dashboard -n default
$ kubectl create clusterrolebinding dashboard-admin -n default --clusterrole=cluster-admin --serviceaccount=default:dashboard clusterrolebinding "dashboard-admin" created
$ kubectl get secret $(kubectl get serviceaccount dashboard -o jsonpath="{.secrets[0].name}") -o jsonpath="{.data.token}" | base64 --decode
この他のブログ記事を確認すると、kube-admin namespaceのTokenを確認して入力しているものもあります。
(【IBM Cloud k8s】WebUI (Dashboard)への認証方法のメモ)[https://qiita.com/MahoTakara/items/fc2e3758d0418001b0a2]
$ kubectl -n kube-system get secret | grep ^default
$ KSUSER=$(kubectl -n kube-system get secret | grep ^default | cut -d' ' -f1)
$ kubectl -n kube-system describe secret $KSUSER
ここで得られたTokenをそのまま利用すると、下記のようなエラーが表示されています。
warning configmaps is forbidden: User "system:serviceaccount:kube-system:default" cannot list configmaps in the namespace "default"
warning persistentvolumeclaims is forbidden: User "system:serviceaccount:kube-system:default" cannot list persistentvolumeclaims in the namespace "default"
ここで、記事の参考文献にある、Kubernetes 1.8のアクセス制御について。あとDashboard。 を読んでみます。
そうすると、うまくいった default namespaceにdashboardアカウントを作成した時に実行したコマンドの意味が理解できました。
## 先に実行しているコマンド
## $ kubectl create clusterrolebinding dashboard-admin -n default --clusterrole=cluster-admin --serviceaccount=default:dashboard clusterrolebinding "dashboard-admin" created
ちょっとよく分からない点は、"cluster-admin"と"dashboard-admin" roleの違いで、文脈から、"dashboard-admin"はWebUI側で想定しているAdmin権限だろうと思いますが、"cluster-admin"を指定する意味が不明瞭です。
Kubernetesの公式リファレンスを検索するとUsing RBAC Authorization - User-facing Rolesの中に、"cluster-admin"についての記述がみつかります。
Some of the default roles are not system: prefixed. These are intended to be user-facing roles. They include super-user roles (cluster-admin), roles intended to be granted cluster-wide using ClusterRoleBindings (cluster-status), and roles intended to be granted within particular namespaces using RoleBindings (admin, edit, view).
ちなみに、"dashboard-admin"については、Github kubernetes/dashboard Wiki - Access Controlの中に記述があります。
You can grant full admin privileges to Dashboard's Service Account by creating below ClusterRoleBinding. Copy the YAML file based on chosen installation method and save as, i.e. dashboard-admin.yaml. Use kubectl create -f dashboard-admin.yaml to deploy it. Afterwards you can use Skip option on login page to access Dashboard.
ここに書かれている手順そのものは、危険ですが、内容を読むと、およそ"dashboard-admin"の文字列自体にはおよそ意味がないことが分かります。
あとは、kubectlコマンドを利用して、$ kubectl get clusterrolles などを実行していきつつ、関連するリファンスを読んでいくことにします。
以上