joinコマンドを再発行する

1台目のControlPlaneを作った時点で，kubeadmからjoinコマンドが提示されていた．

$ kubeadm join kube-apiserver.h3poteto.local:10443 --token hogehoge.fugafuga \
  --discovery-token-ca-cert-hash sha256:hogehogefugafuga \
  --control-plane

このtokenは24時間で有効期限が切れてしまうので，今回のようなケースではとうの昔に期限切れになっている．というわけで，新しいtokenを使ったjoinコマンドを再発行してもらう．

1台目に入り，

$ kubeadm token create --print-join-command

とかすると，新しいtokenを使ったjoinコマンドが再発行される．これを2台目以降のControlPlaneで実行する．

しかし，ControlPlaneの場合，これだけだと不足していて，

[preflight] Running pre-flight checks
[preflight] Reading configuration from the cluster...
[preflight] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
error execution phase preflight:
One or more conditions for hosting a new control plane instance is not satisfied.

[failure loading certificate for CA: couldn't load the certificate file /etc/kubernetes/pki/ca.crt: open /etc/kubernetes/pki/ca.crt: no such file or directory, failure loading key for service account: couldn't load the private key file /etc/kubernetes/pki/sa.key: open /etc/kubernetes/pki/sa.key: no such file or directory, failure loading certificate for front-proxy CA: couldn't load the certificate file /etc/kubernetes/pki/front-proxy-ca.crt: open /etc/kubernetes/pki/front-proxy-ca.crt: no such file or directory, failure loading certificate for etcd CA: couldn't load the certificate file /etc/kubernetes/pki/etcd/ca.crt: open /etc/kubernetes/pki/etcd/ca.crt: no such file or directory]

Please ensure that:
 The cluster has a stable controlPlaneEndpoint address.
 The certificates that must be shared among control plane instances are provided.


To see the stack trace of this error execute with --v=5 or higher

というようなエラーになる．

Certificateを探す

前述のエラーを見ると， /etc/kubernetes/pki/ca.crt がないと言われている．確かにそんなものはない．これは手動でコピーしてきて，ここに配置してもいいのだけれど，kubeadmで自動的に行っても良い．

まず，1台目のControlPlaneに戻る．

ここで

$ sudo kubeadm init phase upload-certs --upload-certs
[upload-certs] Storing the certificates in Secret "kubeadm-certs" in the "kube-system" Namespace
[upload-certs] Using certificate key:
xxxxxxx

をやる．

kubeadmはこのようにinit時のphaseを個別に指定して実行することができる．で，upload-certsをやると，certificateの内容がSecretsに書き込まれる．で， --certificate-key を指定することで，そのSecretから /etc/kubernetes/pki/ca.crt 等の必要な証明書を作ってくれる．

というわけで，2台目で

$ kubeadm join kube-apiserver.h3poteto.local:10443 --token hogehoge.fugafuga \
  --discovery-token-ca-cert-hash sha256:hogehogefugafuga \
  --control-plane \
  --certificate-key xxxxxx

--certificate-keyにupload-certsで出てきたcertificate keyを貼り付けると，無事joinできる．

あとは3台目も同じコマンドでいける．

HAProxyを3台用に更新

h3poteto.hatenablog.com

ここで紹介していた，haproxyの設定を更新して，3台にリクエストを分散できるようにしていく．

backend kube-apiserver
        mode tcp
        option tcplog
        option tcp-check
        balance roundrobin
        default-server inter 10s downinter 5s rise 2 fall 2 slowstart 60s maxconn 250 maxqueue 256 weight 100
        server kube-apiserver-1 192.168.0.50:6443 check
        server kube-apiserver-2 192.168.0.51:6443 check
        server kube-apiserver-3 192.168.0.51:6443 check

keepalivedも3台対応しておく．

vrrp_instance haproxy-vip {
  state BACKUP
  priority 100
  interface wlan0                       # Network card
  virtual_router_id 60
  advert_int 1
  authentication {
    auth_type PASS
    auth_pass 1111
  }
  unicast_src_ip 192.168.0.50      # The IP address of this machine
  unicast_peer {                        # The IP address of peer machines
    192.168.0.50
    192.168.0.51
    192.168.0.52
  }

  virtual_ipaddress {
    192.168.0.40/24                  # The VIP address
  }

  track_script {
    chk_haproxy
  }
}

これで，たとえ1台が死んだとしても，VIPでアクセスしていれば2台目以降がレスポンスを返してくれる．