#初めに
「kubernetes the hard way を PC でやってみる」の１０回目、「Bootstrapping the Kubernetes Control Plane」についてです。（目次）

kubernetes の中心的な機能を果たす control plane のセットアップです。
バイナリ入手はどれかの control plane で実施して、コピーすればよいですが、
それ以降については ※3台の control plane ノードで実施します※

やることは以下の通りです。

kubernetes バイナリの入手
API サーバーの構成
Controller-manager の構成
Scheduler の構成
Controller サービスの起動
HTTP Health Check
kubelet 用の RBAC 設定
The Kubernetes Frontend Load Balancer

図で言うと赤枠の部分です。
ただし、外部ロードバランサーを用意していない関係で、
HTTP Health Check 並びに The Kubernetes Frontend Load Balancer は割愛しています。

※ kubernetes the hard way では google cloud の Network load balancer を構成していますが
オンプレではできないので割愛しています。（他のロードバランサーでやってみようか、とは思いましたがあきらめ…）

また、末尾につまづいたエラーとその調査・対応方法も記載しておきます。

kubernetes バイナリの入手

kubernetes の最新版は git hub 上で確認することができます。
以下の URL アクセス後、右側の列の Releases 欄に最新版が記載されています。
https://github.com/kubernetes/kubernetes

2020/07 時点では、 v1.18.6 でした。
Releases 欄のバージョン部分をクリックするとリリースページに遷移します。　そのページ下部にダウンロードできるリンクがあります。
https://github.com/kubernetes/kubernetes/releases/download/v1.18.6/kubernetes.tar.gz

kubernetes the hard way では、各コンポーネントのバイナリを個別に取得する手順になっていますが、
最近は kubernetes.tar.gz となっており、その中のスクリプトを実行してバイナリを取得する構成のようです。

私が実施した際は、 v1.16.9 で、 URL としては以下の通りでした。今でもなぜ 1.16 でやったのか理解に苦しみます。
https://github.com/kubernetes/kubernetes/releases/download/v1.16.9/kubernetes.tar.gz

これを wget でダウンロードします。

# wget -q --show-progress --https-only --timestamping https://github.com/kubernetes/kubernetes/releases/download/v1.16.9/kubernetes.tar.gz
kubernetes.tar.gz                                        100%[================================================================================================================================>] 445.60K   214KB/s    in 2.1s

ダウンロード完了後、展開し、 kubernetes/cluster まで移動します。

# tar zxf kubernetes.tar.gz
# ls
ca  etcd  kubernetes  kubernetes-client-linux-amd64.tar.gz  kubernetes.tar.gz

# cd kubernetes/
# ls
client  cluster  docs  hack  LICENSES  README.md  server  version

# cd cluster/
# ls
addons  clientbin.sh  gce                   get-kube-local.sh  images  kubeadm.sh  kube-down.sh  kubernetes-anywhere  kube-util.sh  OWNERS        README.md               skeleton     test-network.sh  update-storage-objects.sh
BUILD   common.sh     get-kube-binaries.sh  get-kube.sh        juju    kubectl.sh  kubemark      kube-up.sh           log-dump      pre-existing  restore-from-backup.sh  test-e2e.sh  test-smoke.sh    validate-cluster.sh

そこで、get-kube-binaries.sh を実行します。途中で、ダウンロードするかどうか聞かれるので y を押します。

# ./get-kube-binaries.sh
Kubernetes release: v1.16.9
Server: linux/amd64  (to override, set KUBERNETES_SERVER_ARCH)
Client: linux/amd64  (autodetected)  (to override, set KUBERNETES_CLIENT_OS and/or KUBERNETES_CLIENT_ARCH)

Will download kubernetes-server-linux-amd64.tar.gz from https://dl.k8s.io/v1.16.9
Will download and extract kubernetes-client-linux-amd64.tar.gz from https://dl.k8s.io/v1.16.9
Is this ok? [Y]/n
y
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   161  100   161    0     0    473      0 --:--:-- --:--:-- --:--:--   473
100  352M  100  352M    0     0  59.2M      0  0:00:05  0:00:05 --:--:-- 78.4M

md5sum(kubernetes-server-linux-amd64.tar.gz)=f606d0f63fd751f857c66e33454cfcbf
sha1sum(kubernetes-server-linux-amd64.tar.gz)=8b3b190f84463dfba117cf49a82c5a58eeb6e67b

  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   161  100   161    0     0   1025      0 --:--:-- --:--:-- --:--:--  1025
100 12.3M  100 12.3M    0     0  9774k      0  0:00:01  0:00:01 --:--:-- 29.9M

md5sum(kubernetes-client-linux-amd64.tar.gz)=e9c4ca5fdb50619d35531b859aadc2bd
sha1sum(kubernetes-client-linux-amd64.tar.gz)=cd0cd90c99a461ae3ff12a569b902e58653a1e9b

Extracting /data/assam/k8s/kubernetes/client/kubernetes-client-linux-amd64.tar.gz into /data/assam/k8s/kubernetes/platforms/linux/amd64
Add '/data/assam/k8s/kubernetes/client/bin' to your PATH to use newly-installed binaries.

メッセージでは kubernetes/client/bin に PATH を通すという指示になっていますが、
kubernetes/client/bin 以下には kubectl がダウンロードされているだけです。
サーバー用のコンポーネントは kubernetes/server 以下にダウンロードされています。
それをさらに展開します。展開した先の kubernetes/server/bin 以下に各種コンポーネントがあります。

# cd ../server
# ls
README  kubernetes-manifests.tar.gz  kubernetes-server-linux-amd64.tar.gz

# tar zxf kubernetes-server-linux-amd64.tar.gz
# ls
README  kubernetes  kubernetes-manifests.tar.gz  kubernetes-server-linux-amd64.tar.gz

# cd kubernetes/server/bin
# ls
apiextensions-apiserver    kube-apiserver.tar                  kube-proxy             kube-scheduler.docker_tag  kubelet
hyperkube                  kube-controller-manager             kube-proxy.docker_tag  kube-scheduler.tar         mounter
kube-apiserver             kube-controller-manager.docker_tag  kube-proxy.tar         kubeadm
kube-apiserver.docker_tag  kube-controller-manager.tar         kube-scheduler         kubectl

上記の各コンポーネントのうち、以下のものを各 control plane ノードの /usr/local/bin 以下にコピーします。
（方法はお任せで。あと念のため実行権限も確認してください。）

kube-apiserver
kube-controller-manager
kube-scheduler
kubectl

#API サーバーの構成

kubernetes の中心ともいえる API サーバーを構成します。
まず、ディレクトリを作成し、その中に各種秘密鍵や証明書をコピーします。
証明書は第６回の最後で各ノードの作業ユーザーのホームディレクトリに配置したと思います。

# mkdir -p /var/lib/kubernetes/
# cp ca.pem ca-key.pem kubernetes.pem kubernetes-key.pem service-account.pem service-account-key.pem encryption-config.yaml /var/lib/kubernetes/
# ls -l /var/lib/kubernetes/
total 28
-rw------- 1 root root 1675 May  9 05:34 ca-key.pem
-rw-r--r-- 1 root root 1318 May  9 05:34 ca.pem
-rw-r--r-- 1 root root  240 May  9 05:34 encryption-config.yaml
-rw------- 1 root root 1679 May  9 05:34 kubernetes-key.pem
-rw-r--r-- 1 root root 1728 May  9 05:34 kubernetes.pem
-rw------- 1 root root 1679 May  9 05:34 service-account-key.pem
-rw-r--r-- 1 root root 1440 May  9 05:34 service-account.pem

次に、 API サーバーを systemd 配下のサービスとして稼働させるために、
ユニットファイルを作成します。

長いので、 kubernetes the hard way からまずテキストファイル等にコピー＆ペーストして実施すればよいです。
違いは以下のポイントです

ここでは root ユーザーで作業しているので、 sudo は不要（と言いつつ後半面倒になって使っています)
IP アドレスが異なる

kubernetes the hard way と合わせた名前、IP 等にしていれば単純にコピー＆ペーストで
対応可能なのですが、最初に何も考えずにホスト名、IP 等を決めてしまったツケが出ていますね。。
（ただ、そのおかげで注意深く見ながらやることになり、結果として理解が深まったかもしれません）

例によって、cat コマンドでファイルを作るため、事前に IP アドレス等を変数に入れています。
kubernetes the hard way では Google cloud のコマンドで IP を取得していますが、
こちらはオンプレPC ですので、以下のように ip コマンドで取得します。

tmux で３台同時に操作する前提でコマンドを用いて IP を変数に格納していますが、
１台ずつ実施する場合は INTERNAL_IP=192.168.199.200 等で全く問題ありません。

# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 52:54:00:01:97:f0 brd ff:ff:ff:ff:ff:ff
    inet 192.168.199.200/24 brd 192.168.199.255 scope global enp1s0
       valid_lft forever preferred_lft forever

# ip addr | grep 192.168 | awk '{ print $2 }' | cut -d / -f 1
192.168.199.200

# INTERNAL_IP=$( ip addr | grep 192.168 | awk '{ print $2 }' | cut -d / -f 1 )
# echo ${INTERNAL_IP}
192.168.199.200

変数の設定ができれば、いよいよ API Server のユニットファイルを作成します。

繰り返しになりますが、ここから先は　
INTERNAL_IP などに注意しながら Control plane のノード３台それぞれで作成します。

# cat <<EOF | tee /etc/systemd/system/kube-apiserver.service
> [Unit]
> Description=Kubernetes API Server
> Documentation=https://github.com/kubernetes/kubernetes
>
> [Service]
> ExecStart=/usr/local/bin/kube-apiserver \\
>   --advertise-address=${INTERNAL_IP} \\
>   --allow-privileged=true \\
>   --apiserver-count=3 \\
>   --audit-log-maxage=30 \\
>   --audit-log-maxbackup=3 \\
>   --audit-log-maxsize=100 \\
>   --audit-log-path=/var/log/audit.log \\
>   --authorization-mode=Node,RBAC \\
>   --enable-admission-plugins=NamespaceLifecycle,NodeRestriction,LimitRanger,ServiceAccount,DefaultStorageClass,ResourceQuota \\
>   --etcd-cafile=/var/lib/kubernetes/ca.pem \\
>   --etcd-certfile=/var/lib/kubernetes/kubernetes.pem \\
>   --etcd-keyfile=/var/lib/kubernetes/kubernetes-key.pem \\
>   --etcd-servers=https://192.168.199.200:2379,https://192.168.199.201:2379,https://192.168.199.202:2379 \\
>   --event-ttl=1h \\
>   --encryption-provider-config=/var/lib/kubernetes/encryption-config.yaml \\
>   --kubelet-certificate-authority=/var/lib/kubernetes/ca.pem \\
>   --kubelet-client-certificate=/var/lib/kubernetes/kubernetes.pem \\
>   --kubelet-client-key=/var/lib/kubernetes/kubernetes-key.pem \\
>   --kubelet-https=true \\
>   --runtime-config=api/all \\
>   --service-account-key-file=/var/lib/kubernetes/service-account.pem \\
[Service]
ExecStart=/usr/local/bin/kube-apiserver \
  --advertise-address=192.168.199.200 \
  --allow-privileged=true \
  --apiserver-count=3 \
  --audit-log-maxage=30 \
  --audit-log-maxbackup=3 \
  --audit-log-maxsize=100 \
  --audit-log-path=/var/log/audit.log \
  --authorization-mode=Node,RBAC \
  --bind-address=0.0.0.0 \
  --client-ca-file=/var/lib/kubernetes/ca.pem \
  --enable-admission-plugins=NamespaceLifecycle,NodeRestriction,LimitRanger,ServiceAccount,DefaultStorageClass,ResourceQuota \
  --etcd-cafile=/var/lib/kubernetes/ca.pem \
  --etcd-certfile=/var/lib/kubernetes/kubernetes.pem \
  --etcd-keyfile=/var/lib/kubernetes/kubernetes-key.pem \
  --etcd-servers=https://192.168.199.200:2379,https://192.168.199.201:2379,https://192.168.199.202:2379 \
  --event-ttl=1h \
  --encryption-provider-config=/var/lib/kubernetes/encryption-config.yaml \
  --kubelet-certificate-authority=/var/lib/kubernetes/ca.pem \
  --kubelet-client-certificate=/var/lib/kubernetes/kubernetes.pem \
  --kubelet-client-key=/var/lib/kubernetes/kubernetes-key.pem \
  --kubelet-https=true \
  --runtime-config=api/all \
  --service-account-key-file=/var/lib/kubernetes/service-account.pem \
  --service-cluster-ip-range=10.32.0.0/24 \
  --service-node-port-range=30000-32767 \
  --tls-cert-file=/var/lib/kubernetes/kubernetes.pem \
  --tls-private-key-file=/var/lib/kubernetes/kubernetes-key.pem \
  --v=2
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target
#

よく見ると、各種証明書の指定や、 encryption-config.yaml の指定、クラスターIP レンジやポートレンジの指定が行われていることがわかります。
--service-cluster-ip-range=10.32.0.0 を指定しているので、 kubernetes 上でサービスを作成すると 10.32.0.0 のNW からアドレスが払い出されます。
また、 NodePort を作成する際のポートは 30000-32767 になります。
API サーバーの各種オプションについては、 Command Line tools reference の kube-apiserver をご覧ください。

API サーバーの準備はここまでです。　systemd のユニットファイルを作成しているので、
systemctl daemon-reload の実行と systemctl list-unit-files | grep xxx で確認したりする必要がありますが、
他にも同様にユニットファイルを作成するため、最後にまとめて実施します。

#Controller-manager の構成

まず、第７回で作成・配布した kubeconfig ファイルをコピーします。

# cp kube-controller-manager.kubeconfig /var/lib/kubernetes/

API サーバー同様、ユニットファイルを作成します。
--cluster-cidr=10.200.0.0/16 を指定していますね。

# cat <<EOF | sudo tee /etc/systemd/system/kube-controller-manager.service
> [Unit]
> Description=Kubernetes Controller Manager
> Documentation=https://github.com/kubernetes/kubernetes
>
> [Service]
> ExecStart=/usr/local/bin/kube-controller-manager \\
>   --address=0.0.0.0 \\
>   --cluster-cidr=10.200.0.0/16 \\
>   --cluster-name=kubernetes \\
>   --cluster-signing-cert-file=/var/lib/kubernetes/ca.pem \\
>   --cluster-signing-key-file=/var/lib/kubernetes/ca-key.pem \\
>   --kubeconfig=/var/lib/kubernetes/kube-controller-manager.kubeconfig \\
>   --leader-elect=true \\
>   --root-ca-file=/var/lib/kubernetes/ca.pem \\
>   --service-account-private-key-file=/var/lib/kubernetes/service-account-key.pem \\
>   --service-cluster-ip-range=10.32.0.0/24 \\
>   --use-service-account-credentials=true \\
>   --v=2
> Restart=on-failure
> RestartSec=5
>
> [Install]
> WantedBy=multi-user.target
> EOF
[Unit]
Description=Kubernetes Controller Manager
Documentation=https://github.com/kubernetes/kubernetes

[Service]
ExecStart=/usr/local/bin/kube-controller-manager \
  --address=0.0.0.0 \
  --cluster-cidr=10.200.0.0/16 \
  --cluster-name=kubernetes \
  --cluster-signing-cert-file=/var/lib/kubernetes/ca.pem \
  --cluster-signing-key-file=/var/lib/kubernetes/ca-key.pem \
  --kubeconfig=/var/lib/kubernetes/kube-controller-manager.kubeconfig \
  --leader-elect=true \
  --root-ca-file=/var/lib/kubernetes/ca.pem \
  --service-account-private-key-file=/var/lib/kubernetes/service-account-key.pem \
  --service-cluster-ip-range=10.32.0.0/24 \
  --use-service-account-credentials=true \
  --v=2
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target
#

オプションについては API サーバー同様に
Command Line tools reference の kube-controller-manager をご覧ください。

#Scheduler の構成

Scheduler についても同様に対応します。

# cp kube-scheduler.kubeconfig /var/lib/kubernetes/

同様に、と言いつつ　scheduler に関しては yaml の設定ファイルが必要なようです。
この辺りはあまり丁寧に確認していないのですが、
kube-scheduler を systemd 配下のサービスではなく、コンテナで動かす場合
この yaml ファイルにコンテナ関連の設定を行い、
static pod として各ノード上で稼働させるということをやるようです。
ただ、今回はあくまで systemd 配下で稼働させるため、
内容としては kubeconfig ファイルの指定と、 Leader Election を行うかどうかの設定ぐらいのようです。
（※ static pod とは kubelet に直接管理される pod で、
乱暴に言うと、あらかじめ指定したディレクトリ内に Pod 用 yaml ファイルを置くと kubelet が起動、管理してくれるというものです）

# cat <<EOF | sudo tee /etc/kubernetes/config/kube-scheduler.yaml
> apiVersion: kubescheduler.config.k8s.io/v1alpha1
> kind: KubeSchedulerConfiguration
> clientConnection:
>   kubeconfig: "/var/lib/kubernetes/kube-scheduler.kubeconfig"
> leaderElection:
>   leaderElect: true
> EOF
apiVersion: kubescheduler.config.k8s.io/v1alpha1
kind: KubeSchedulerConfiguration
clientConnection:
  kubeconfig: "/var/lib/kubernetes/kube-scheduler.kubeconfig"
leaderElection:
  leaderElect: true
#

次にユニットファイルを作成します。

# cat <<EOF | sudo tee /etc/systemd/system/kube-scheduler.service
> [Unit]
> Description=Kubernetes Scheduler
> Documentation=https://github.com/kubernetes/kubernetes
>
> [Service]
> ExecStart=/usr/local/bin/kube-scheduler \\
>   --config=/etc/kubernetes/config/kube-scheduler.yaml \\
>   --v=2
> Restart=on-failure
> RestartSec=5
>
> [Install]
> WantedBy=multi-user.target
> EOF
[Unit]
Description=Kubernetes Scheduler
Documentation=https://github.com/kubernetes/kubernetes

[Service]
ExecStart=/usr/local/bin/kube-scheduler \
  --config=/etc/kubernetes/config/kube-scheduler.yaml \
  --v=2
Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target
#

オプションについては API サーバー同様に
Command Line tools reference の kube-scheduler をご覧ください。

#Controller サービスの起動

ここまで作成してきたユニットファイルを用いて、 systemd 配下で動かす kubernetes の各種サービスを起動します。
まずは daemon-reload です。

# systemctl daemon-reload

次に、ユニットファイルに間違いがないか簡易的に確認します。
(※３列表示ですが、前から　ユニット・ファイル、STATE、VENDOR PRESET の順です。　VENDOR PRESET は一言でいえばデフォルトです。）
STATE欄が bad となっていればユニットファイル見直しです。

# systemctl list-unit-files | grep kube
kube-apiserver.service                 disabled        enabled
kube-controller-manager.service        disabled        enabled
kube-scheduler.service                 disabled        enabled

次に、先に自動起動設定をしておきます。

# systemctl enable kube-apiserver kube-controller-manager kube-scheduler

Created symlink /etc/systemd/system/multi-user.target.wants/kube-apiserver.service → /etc/systemd/system/kube-apiserver.service.
Created symlink /etc/systemd/system/multi-user.target.wants/kube-controller-manager.service → /etc/systemd/system/kube-controller-manager.service.
Created symlink /etc/systemd/system/multi-user.target.wants/kube-scheduler.service → /etc/systemd/system/kube-scheduler.service.

# systemctl list-unit-files | grep kube
kube-apiserver.service                 enabled         enabled
kube-controller-manager.service        enabled         enabled
kube-scheduler.service                 enabled         enabled

そして、いよいよ起動です。

##API サーバー起動

systemctl コマンドで起動し、 systemctl status でステータスを見ています。 loaded , active になっているので起動しています。
なお、ログ末尾に healthz check failed となっていますが、現時点では気にする必要はありません。
まだクラスターが構成されていないためのようです。

# systemctl start kube-apiserver
# echo $?
0

# systemctl status kube-apiserver
● kube-apiserver.service - Kubernetes API Server
     Loaded: loaded (/etc/systemd/system/kube-apiserver.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2020-05-09 05:46:22 UTC; 11s ago
       Docs: https://github.com/kubernetes/kubernetes
   Main PID: 2625 (kube-apiserver)
      Tasks: 11 (limit: 2282)
     Memory: 273.2M
     CGroup: /system.slice/kube-apiserver.service
             mq2625 /usr/local/bin/kube-apiserver --advertise-address=192.168.199.200 --allow-privileged=true --apiserver-count=3 --audit-log-maxage=30 --audit-log-maxbackup=3 --audit-log-maxsize=100 --audit-log-path=/var/log>

May 09 05:46:33 k8smaster0 kube-apiserver[2625]: [+]poststarthook/start-apiextensions-informers ok
May 09 05:46:33 k8smaster0 kube-apiserver[2625]: [+]poststarthook/start-apiextensions-controllers ok
May 09 05:46:33 k8smaster0 kube-apiserver[2625]: [+]poststarthook/crd-informer-synced ok
May 09 05:46:33 k8smaster0 kube-apiserver[2625]: [+]poststarthook/bootstrap-controller ok
May 09 05:46:33 k8smaster0 kube-apiserver[2625]: [-]poststarthook/rbac/bootstrap-roles failed: reason withheld
May 09 05:46:33 k8smaster0 kube-apiserver[2625]: [+]poststarthook/scheduling/bootstrap-system-priority-classes ok
May 09 05:46:33 k8smaster0 kube-apiserver[2625]: [+]poststarthook/ca-registration ok
May 09 05:46:33 k8smaster0 kube-apiserver[2625]: [+]poststarthook/start-kube-apiserver-admission-initializer ok
May 09 05:46:33 k8smaster0 kube-apiserver[2625]: [+]poststarthook/start-kube-aggregator-informers ok
May 09 05:46:33 k8smaster0 kube-apiserver[2625]: [+]poststarthook/apiservice-registration-controller ok
May 09 05:46:33 k8smaster0 kube-apiserver[2625]: [+]poststarthook/apiservice-status-available-controller ok
May 09 05:46:33 k8smaster0 kube-apiserver[2625]: [+]poststarthook/kube-apiserver-autoregistration ok
May 09 05:46:33 k8smaster0 kube-apiserver[2625]: [+]autoregister-completion ok
May 09 05:46:33 k8smaster0 kube-apiserver[2625]: [+]poststarthook/apiservice-openapi-controller ok
May 09 05:46:33 k8smaster0 kube-apiserver[2625]: healthz check failed

なお、ログをすべて確認する場合は、journalctl -u kube-apiserver でご確認ください。
一度ぐらいは少し時間をかけて　わからないながらも見ておいてもよいと思います。

単体レベルで確認したい場合は以下のようなコマンドで確認するようです。(admin.kubeconfig がある場所で実行）

# kubectl get --raw /healthz/poststarthook/rbac/bootstrap-roles --kubeconfig admin.kubeconfig
ok

##kube-controller-manager 起動

# systemctl start kube-controller-manager
# echo $?
0

# systemctl status kube-controller-manager
  kube-controller-manager.service - Kubernetes Controller Manager
     Loaded: loaded (/etc/systemd/system/kube-controller-manager.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2020-05-09 05:57:23 UTC; 7s ago
       Docs: https://github.com/kubernetes/kubernetes
   Main PID: 2654 (kube-controller)
      Tasks: 8 (limit: 2282)
     Memory: 21.5M
     CGroup: /system.slice/kube-controller-manager.service
             mq2654 /usr/local/bin/kube-controller-manager --address=0.0.0.0 --cluster-cidr=10.200.0.0/16 --cluster-name=kubernetes --cluster-signing-cert-file=/var/lib/kubernetes/ca.pem --cluster-signing-key-file=/var/lib/ku>

May 09 05:57:30 k8smaster0 kube-controller-manager[2654]: I0509 05:57:30.727766    2654 controllermanager.go:519] Starting "cronjob"
May 09 05:57:30 k8smaster0 kube-controller-manager[2654]: I0509 05:57:30.727830    2654 attach_detach_controller.go:334] Starting attach detach controller
May 09 05:57:30 k8smaster0 kube-controller-manager[2654]: I0509 05:57:30.727906    2654 shared_informer.go:197] Waiting for caches to sync for attach detach
May 09 05:57:30 k8smaster0 kube-controller-manager[2654]: I0509 05:57:30.967158    2654 controllermanager.go:534] Started "cronjob"
May 09 05:57:30 k8smaster0 kube-controller-manager[2654]: I0509 05:57:30.968030    2654 controllermanager.go:519] Starting "csrsigning"
May 09 05:57:30 k8smaster0 kube-controller-manager[2654]: I0509 05:57:30.967999    2654 cronjob_controller.go:96] Starting CronJob Manager
May 09 05:57:31 k8smaster0 kube-controller-manager[2654]: I0509 05:57:31.118212    2654 controllermanager.go:534] Started "csrsigning"
May 09 05:57:31 k8smaster0 kube-controller-manager[2654]: I0509 05:57:31.118276    2654 controllermanager.go:519] Starting "clusterrole-aggregation"
May 09 05:57:31 k8smaster0 kube-controller-manager[2654]: I0509 05:57:31.118359    2654 certificate_controller.go:113] Starting certificate controller
May 09 05:57:31 k8smaster0 kube-controller-manager[2654]: I0509 05:57:31.118374    2654 shared_informer.go:197] Waiting for caches to sync for certificate

Starting "cronjob" などとなっていますね。　controller-manager は cronjob で Reconciliation loop を回しているんでしょうね。

##kube-scheduler 起動

# systemctl start kube-scheduler
# echo $?
0

# systemctl status kube-scheduler
● kube-scheduler.service - Kubernetes Scheduler
     Loaded: loaded (/etc/systemd/system/kube-scheduler.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2020-05-09 05:59:55 UTC; 10s ago
       Docs: https://github.com/kubernetes/kubernetes
   Main PID: 2689 (kube-scheduler)
      Tasks: 10 (limit: 2282)
     Memory: 8.7M
     CGroup: /system.slice/kube-scheduler.service
             mq2689 /usr/local/bin/kube-scheduler --config=/etc/kubernetes/config/kube-scheduler.yaml --v=2

May 09 05:59:57 k8smaster0 kube-scheduler[2689]: I0509 05:59:57.432942    2689 server.go:148] Version: v1.16.9
May 09 05:59:57 k8smaster0 kube-scheduler[2689]: I0509 05:59:57.433059    2689 defaults.go:91] TaintNodesByCondition is enabled, PodToleratesNodeTaints predicate is mandatory
May 09 05:59:57 k8smaster0 kube-scheduler[2689]: I0509 05:59:57.433080    2689 server.go:167] Starting Kubernetes Scheduler version v1.16.9
May 09 05:59:57 k8smaster0 kube-scheduler[2689]: I0509 05:59:57.447008    2689 factory.go:294] Creating scheduler from algorithm provider 'DefaultProvider'
May 09 05:59:57 k8smaster0 kube-scheduler[2689]: I0509 05:59:57.447053    2689 factory.go:382] Creating scheduler with fit predicates 'map[CheckNodeUnschedulable:{} CheckVolumeBinding:{} GeneralPredicates:{} MatchInterPodAffi>
May 09 05:59:57 k8smaster0 kube-scheduler[2689]: W0509 05:59:57.450788    2689 authorization.go:47] Authorization is disabled
May 09 05:59:57 k8smaster0 kube-scheduler[2689]: W0509 05:59:57.451153    2689 authentication.go:79] Authentication is disabled
May 09 05:59:57 k8smaster0 kube-scheduler[2689]: I0509 05:59:57.451387    2689 deprecated_insecure_serving.go:51] Serving healthz insecurely on 0.0.0.0:10251
May 09 05:59:57 k8smaster0 kube-scheduler[2689]: I0509 05:59:57.453170    2689 secure_serving.go:123] Serving securely on 0.0.0.0:10259
May 09 05:59:57 k8smaster0 kube-scheduler[2689]: I0509 05:59:57.553817    2689 leaderelection.go:241] attempting to acquire leader lease  kube-system/kube-scheduler...

ログの末尾で、 Leader Election が開始されているのがわかります。
（ただし、このログの時点では他のノードの scheduler が起動していないのでうまく Leader にはなれませんが…）

##起動結果確認

各コンポーネントが問題ないことを確認します。
すると、下記のように表示されるはずです。　

# kubectl get componentstatuses --kubeconfig admin.kubeconfig
# kubectl get componentstatus
NAME                 STATUS    MESSAGE             ERROR
controller-manager   Healthy   ok
scheduler            Healthy   ok
etcd-0               Healthy   {"health":"true"}
etcd-1               Healthy   {"health":"true"}
etcd-2               Healthy   {"health":"true"}

実際には、 v1.16 では　下記のようになります。

NAME                 AGE
scheduler            <unknown>
controller-manager   <unknown>
etcd-0               <unknown>
etcd-2               <unknown>
etcd-1               <unknown>

これは v1.16 のバグで、 v1.17 では修正されています。
もう少し詳しくは末尾のエラーの説明部分に記載します。

#HTTP Health Check

HTTP Health Check ですが、 kubernetes the hard way では google cloud のロードバランサーからの
Health Check 用途で nginx を入れています。
今回オンプレPC でロードバランサーを入れていないため、あまり実施する意味がありません。
そのため今回は割愛いたします。

#kubelet 用の RBAC 設定

API サーバーから各ノードの kubelet にアクセスするための RBAC 権限設定を行います。
また、ここでの作業は control plane のどれか１ノードで実施すればOKです。
これは kubernetes の世界の中の設定なので etcd 内に格納され、どの control plane ノードからも参照できます。
system:kube-apiserver-to-kubelet という ClusterRole 内で
記載の resource に対する全種類の操作を許可しています。

なお、下記のやり方は標準入力から直接 kubectl apply に内容を渡して設定していますが、
これは個人的には危ないやり方だと思います。
きちんと一度テキストファイルに出力してから apply したほうが良いと思います。

# cat <<EOF | kubectl apply --kubeconfig admin.kubeconfig -f -
> apiVersion: rbac.authorization.k8s.io/v1beta1
> kind: ClusterRole
> metadata:
>   annotations:
>     rbac.authorization.kubernetes.io/autoupdate: "true"
>   labels:
>     kubernetes.io/bootstrapping: rbac-defaults
>   name: system:kube-apiserver-to-kubelet
> rules:
>   - apiGroups:
>       - ""
>     resources:
>       - nodes/proxy
>       - nodes/stats
>       - nodes/log
>       - nodes/spec
>       - nodes/metrics
>     verbs:
>       - "*"
> EOF
clusterrole.rbac.authorization.k8s.io/system:kube-apiserver-to-kubelet created
#

次に ClusterRole をユーザーに結び付ける ClusterRoleBinding を作成します。
roleRef 欄で上記 ClusterRole を指定しています。
また、 subjects 欄で kubernetes というユーザーを指定しています。

# cat <<EOF | kubectl apply --kubeconfig admin.kubeconfig -f -
> apiVersion: rbac.authorization.k8s.io/v1beta1
> kind: ClusterRoleBinding
> metadata:
>   name: system:kube-apiserver
>   namespace: ""
> roleRef:
>   apiGroup: rbac.authorization.k8s.io
>   kind: ClusterRole
>   name: system:kube-apiserver-to-kubelet
> subjects:
>   - apiGroup: rbac.authorization.k8s.io
>     kind: User
>     name: kubernetes
> EOF
clusterrolebinding.rbac.authorization.k8s.io/system:kube-apiserver created

一応作成されたことを見ておきましょう。

root@k8smaster0:/data/assam/k8s/ca# kubectl --kubeconfig admin.kubeconfig get ClusterRole
NAME                                                                   AGE
admin                                                                  30m
cluster-admin                                                          30m
edit                                                                   30m
system:aggregate-to-admin                                              30m
system:aggregate-to-edit                                               30m
system:aggregate-to-view                                               30m
system:auth-delegator                                                  30m
system:basic-user                                                      30m
system:certificates.k8s.io:certificatesigningrequests:nodeclient       30m
system:certificates.k8s.io:certificatesigningrequests:selfnodeclient   30m
system:controller:attachdetach-controller                              30m
system:controller:certificate-controller                               30m
system:controller:clusterrole-aggregation-controller                   30m
system:controller:cronjob-controller                                   30m
system:controller:daemon-set-controller                                30m
system:controller:deployment-controller                                30m
system:controller:disruption-controller                                30m
system:controller:endpoint-controller                                  30m
system:controller:expand-controller                                    30m
system:controller:generic-garbage-collector                            30m
system:controller:horizontal-pod-autoscaler                            30m
system:controller:job-controller                                       30m
system:controller:namespace-controller                                 30m
system:controller:node-controller                                      30m
system:controller:persistent-volume-binder                             30m
system:controller:pod-garbage-collector                                30m
system:controller:pv-protection-controller                             30m
system:controller:pvc-protection-controller                            30m
system:controller:replicaset-controller                                30m
system:controller:replication-controller                               30m
system:controller:resourcequota-controller                             30m
system:controller:route-controller                                     30m
system:controller:service-account-controller                           30m
system:controller:service-controller                                   30m
system:controller:statefulset-controller                               30m
system:controller:ttl-controller                                       30m
system:csi-external-attacher                                           30m
system:csi-external-provisioner                                        30m
system:discovery                                                       30m
system:heapster                                                        30m
system:kube-aggregator                                                 30m
system:kube-apiserver-to-kubelet                                       3m7s
system:kube-controller-manager                                         30m
system:kube-dns                                                        30m
system:kube-scheduler                                                  30m
system:kubelet-api-admin                                               30m
system:node                                                            30m
system:node-bootstrapper                                               30m
system:node-problem-detector                                           30m
system:node-proxier                                                    30m
system:persistent-volume-provisioner                                   30m
system:public-info-viewer                                              30m
system:volume-scheduler                                                30m
view                                                                   30m
root@k8smaster0:/data/assam/k8s/ca#

１つだけ 3m7s のものがありますね。　簡単に色が変えられればよいんですが…

また、詳細も見ておきます。

# kubectl --kubeconfig admin.kubeconfig get ClusterRole system:kube-apiserver-to-kubelet -o wide
NAME                               AGE
system:kube-apiserver-to-kubelet   4m9s

yaml 形式でも出力させてみましょう。　入力したもの以外にもあれこれついていますが、
内容は同じです。

# kubectl --kubeconfig admin.kubeconfig get ClusterRole system:kube-apiserver-to-kubelet -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"rbac.authorization.k8s.io/v1beta1","kind":"ClusterRole","metadata":{"annotations":{"rbac.authorization.kubernetes.io/autoupdate":"true"},"labels":{"kubernetes.io/bootstrapping":"rbac-defaults"},"name":"system:kube-apiserver-to-kubelet"},"rules":[{"apiGroups":[""],"resources":["nodes/proxy","nodes/stats","nodes/log","nodes/spec","nodes/metrics"],"verbs":["*"]}]}
    rbac.authorization.kubernetes.io/autoupdate: "true"
  creationTimestamp: "2020-05-09T06:14:16Z"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: system:kube-apiserver-to-kubelet
  resourceVersion: "10679"
  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterroles/system%3Akube-apiserver-to-kubelet
  uid: 1b15b2f1-b090-4e4f-98a0-0ee833a49b5e
rules:
- apiGroups:
  - ""
  resources:
  - nodes/proxy
  - nodes/stats
  - nodes/log
  - nodes/spec
  - nodes/metrics
  verbs:
  - '*'

同様に、 ClusterRoleBinding も観ておきましょう。

# kubectl --kubeconfig admin.kubeconfig get ClusterRoleBindings system:kube-apiserver
NAME                    AGE
system:kube-apiserver   4m45s


# kubectl --kubeconfig admin.kubeconfig get ClusterRoleBindings system:kube-apiserver  -o yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: |
      {"apiVersion":"rbac.authorization.k8s.io/v1beta1","kind":"ClusterRoleBinding","metadata":{"annotations":{},"name":"system:kube-apiserver"},"roleRef":{"apiGroup":"rbac.authorization.k8s.io","kind":"ClusterRole","name":"system:kube-apiserver-to-kubelet"},"subjects":[{"apiGroup":"rbac.authorization.k8s.io","kind":"User","name":"kubernetes"}]}
  creationTimestamp: "2020-05-09T06:14:47Z"
  name: system:kube-apiserver
  resourceVersion: "10721"
  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/system%3Akube-apiserver
  uid: 6f67f771-41b3-4e1d-a356-6e58251dc0e6
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:kube-apiserver-to-kubelet
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: User
  name: kubernetes

#The Kubernetes Frontend Load Balancer

ここは Google cloud でのロードバランサー設定のため、
今回は利用しません。
そのため、割愛します。
ロードバランサーからアクセスできるように設定できればかっこいいですが…

（一応、外部のサーバーに nginx のロードバランサーを置いてみようかとトライしましたが
　SSL で受けて SSL で後ろに流す、ということができないようであきらめました。。。）

#エラー並びに調査・対応方法

さて、前回から恒例になりつつあるエラー対応です。
kubernetes the hard way をやっている人は多数いると思いますが、
みんなエラー無く対応できているんでしょうか。。。？？

##1. component status が unknown

本文中でも若干触れましたが、 kubectl get componentstatus が unknown になる、という事象です。

# kubectl get componentstatuses --kubeconfig admin.kubeconfig
NAME                 AGE
scheduler            <unknown>
controller-manager   <unknown>
etcd-0               <unknown>
etcd-2               <unknown>
etcd-1               <unknown>

unknown と言われてもこちらもわかりません、としか言いようがありません。
こういう時はもう少し詳しく聞いてみましょう。
--v=レベル を指定すると、詳細ログが出ます　（下記は、 --v=6 で実施していますが、 4ぐらいからどんどん上げて確認していきました。　なお、 0-4: debug レベル、 5-10: trace レベルだそうです。 9-10 はかなり詳細が出ます。一度ぐらいは眺めてみると理解が深まってよいです。あ、 curl 使っているのね、とか。）

root@k8smaster01:~# kubectl --v=6 get componentstatuses --kubeconfig admin.kubeconfig
I0504 06:15:06.831312    4248 loader.go:375] Config loaded from file:  admin.kubeconfig
I0504 06:15:06.960862    4248 round_trippers.go:443] GET https://127.0.0.1:6443/api/v1/componentstatuses?limit=500 200 OK in 122 milliseconds
I0504 06:15:06.963204    4248 table_printer.go:44] Unable to decode server response into a Table. Falling back to hardcoded types: attempt to decode non-Table object into a v1beta1.Table
I0504 06:15:06.963309    4248 table_printer.go:44] Unable to decode server response into a Table. Falling back to hardcoded types: attempt to decode non-Table object into a v1beta1.Table
I0504 06:15:06.963362    4248 table_printer.go:44] Unable to decode server response into a Table. Falling back to hardcoded types: attempt to decode non-Table object into a v1beta1.Table
NAME                 AGE
scheduler            <unknown>
controller-manager   <unknown>
etcd-0               <unknown>

ログの 2行目 GET https:.... となっているところをよく見ると、以下のように出力されています。
GET https://127.0.0.1:6443/api/v1/componentstatuses?limit=500 200 OK in 122 milliseconds

200 OK となっています。
また、--v=8 から見られる Reponse Body を見ると（見づらいですが）
Type:healthy　とか、 message:ok などのログが見られます。（上記ログでは表示されていません）
また、 table_printer.go というところには、 "Unable to decode server response into a Table..." という記載もあります。
要は、正常なレスポンスが返ってきているが、テーブル形式に変換できていないのではないか、とあたりがつきます。

そこで、形式を変えて表示させます。
丁寧にみると問題なさそうなことが見て取れますね。

# kubectl get componentstatuses --kubeconfig admin.kubeconfig  -o yaml

apiVersion: v1
items:
- apiVersion: v1
  conditions:
  - message: ok
    status: "True"
    type: Healthy
  kind: ComponentStatus
  metadata:
    creationTimestamp: null
    name: scheduler
    selfLink: /api/v1/componentstatuses/scheduler
- apiVersion: v1
  conditions:
  - message: ok
    status: "True"
    type: Healthy
  kind: ComponentStatus
  metadata:
    creationTimestamp: null
    name: controller-manager
    selfLink: /api/v1/componentstatuses/controller-manager
- apiVersion: v1
  conditions:
  - message: '{"health":"true"}'
    status: "True"
    type: Healthy
  kind: ComponentStatus
  metadata:
    creationTimestamp: null
    name: etcd-0
    selfLink: /api/v1/componentstatuses/etcd-0
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

その後、改めて Web で調べてみると、下記のような Issue がありました。
kubectl get componentstatus fails to write as table #83024
https://github.com/kubernetes/kubernetes/issues/83024
v1.17 で修正済みのようです。

##2. kube-apiserver 起動時エラー（その１）

systemctl start kube-apiserver コマンドで API サーバーを起動した際に
ログに以下のようなエラーが出力されました。

# journalctl -u kube-apiserver
（略）
May 03 07:11:39 k8smaster01 kube-apiserver[3133]: Error: error while parsing encryption provider configuration file "/var/lib/kubernetes/encryption-config.yaml": could not obtain secret for named key key1: illegal base64 data

はい、これはもう encryption-config.yaml が間違っている以外の解はなさそうですね。
この時確認すると、ファイルが以下のようになっていました。。。

# cat encryption-config.yaml
kind: EncryptionConfig
apiVersion: v1
resources:
  - resources:
      - secrets
    providers:
      - aescbc:
          keys:
            - name: key1
              secret: ${ENCRYPTION_KEY}
      - identity: {}

コピペするときに変数のことを考えなかったようですね。。。
encryption-config.yaml 作成は第８回で記載しています。
head -c 32 /dev/urandom | base64 の出力文字列を該当の変数部分に修正入力しました。

##3. kube-controller-manager の Leader election 失敗

kube-controller-manager の起動時のエラーです。
正確には、起動はするがログにエラーが出ている、という状態です。

# journalctl -u kube-controller-manager
（略）
May 03 07:46:49 k8smaster01 kube-controller-manager[3622]: E0503 07:46:49.285704    3622 leaderelection.go:330] error retrieving resource lock kube-system/kube-controller-manager: rpc error: code = Unavailable desc = etcdserve
May 03 07:46:51 k8smaster01 kube-controller-manager[3622]: I0503 07:46:51.727629    3622 leaderelection.go:287] failed to renew lease kube-system/kube-controller-manager: failed to tryAcquireOrRenew context deadline exceeded
May 03 07:46:51 k8smaster01 kube-controller-manager[3622]: F0503 07:46:51.727722    3622 controllermanager.go:279] leaderelection lost
May 03 07:46:51 k8smaster01 systemd[1]: kube-controller-manager.service: Main process exited, code=exited, status=255/EXCEPTION
May 03 07:46:51 k8smaster01 systemd[1]: kube-controller-manager.service: Failed with result 'exit-code'.
May 03 07:46:56 k8smaster01 systemd[1]: kube-controller-manager.service: Service RestartSec=5s expired, scheduling restart.
May 03 07:46:56 k8smaster01 systemd[1]: kube-controller-manager.service: Scheduled restart job, restart counter is at 1.
May 03 07:46:56 k8smaster01 systemd[1]: Stopped Kubernetes Controller Manager.
May 03 07:46:56 k8smaster01 systemd[1]: Started Kubernetes Controller Manager.

以下のようなことが見受けられます。

ログ１行目： etcdserve が Unavailable である
ログ２行目： failed to tryAcquireOrRenew context deadline exceeded
ログ３行目： leaderelection lost
ログ４行目： Exit Code 255 で異常終了

etcd からの応答が返ってこずに、 Leader Election が失敗し、 kube-controller-manager 自体が異常終了しているようです。
etcd 自体は稼働していたのですが、　第９回で少しふれたとおり、 CPU リソースが wait 100% になっており
体感的にも以上に遅く、Disk I/O によるタイムアウトだと判断しました。
対応としては、一旦 etcd をシングル構成に格下げしたのですが、最終的には SSD を購入して再度最初からやり直しました。
etcd の Disk I/O は重要です。

※ etcd を　1台構成に変更する方法概要

etcd 停止
/var/lib/etcd/member ディレクトリ削除 (状態を保持しているようです)
etcd.services ファイル修正　（#2, #3 エントリーの削除）
etcd サービスの無効化（ #2, #3 のみ )
etcd 起動（#1 のみ）

※ kube-apiserver.service ファイルから、　etcd #2, #3 のエントリーを削除

なお、 control plane の各種コンポーネントのログについては
一度ぐらいは丁寧に見ておくことをお勧めいたします。
いろんな設定がデフォルトでされているんだな、ということがよくわかります。

今回はここまでとして、次回は Bootstrapping the Kubernetes Worker Nodes の部分を実施します。

← ９．etcd
↑ 目次
→ １１．Worker Nodes