このページでは、kubeadmを使用して、高可用性クラスターを作成する、2つの異なるアプローチを説明します:
先へ進む前に、どちらのアプローチがアプリケーションの要件と、環境に適合するか、慎重に検討してください。こちらの比較が、それぞれの利点/欠点について概説しています。
クラスターではKubernetesのバージョン1.12以降を使用する必要があります。また、kubeadmを使用した高可用性クラスターはまだ実験的な段階であり、将来のバージョンではもっとシンプルになることに注意してください。たとえば、クラスターのアップグレードに際し問題に遭遇するかもしれません。両方のアプローチを試し、kueadmのissue trackerで我々にフィードバックを提供してくれることを推奨します。
alpha feature gateであるHighAvailability
はv1.12で非推奨となり、v1.13で削除されたことに留意してください。
高可用性クラスターのアップグレードも参照してください。
注意: このページはクラウド上でクラスターを構築することには対応していません。ここで説明されているどちらのアプローチも、クラウド上で、LoadBalancerタイプのServiceオブジェクトや、動的なPersistentVolumeを利用して動かすことはできません。
どちらの方法でも、以下のインフラストラクチャーが必要です:
kubeadm
とkubelet
がすべてのマシンにインストールされていること。 kubectl
は任意です。外部etcdクラスターには、以下も必要です:
備考: 以下の例では、CalicoをPodネットワーキングプロバイダーとして使用します。別のネットワーキングプロバイダーを使用する場合、必要に応じてデフォルトの値を変更してください。
備考: コントロールプレーンや、etcdノードでのコマンドはすべてrootとして実行してください。
192.168.0.0/16
のようなCIDRを必要としますが、Weaveなどは必要としません。CNIネットワークドキュメントを参照してください。PodにCIDRを設定するには、ClusterConfiguration
のnetworking
オブジェクトにpodSubnet: 192.168.0.0/16
フィールドを設定してください。備考: ロードバランサーには多くの設定項目があります。以下の例は、一選択肢に過ぎません。あなたのクラスター要件には、異なった設定が必要かもしれません。
DNSで解決される名前で、kube-apiserver用ロードバランサーを作成する。
クラウド環境では、コントロールプレーンノードをTCPフォワーディングロードバランサーの後ろに置かなければなりません。このロードバランサーはターゲットリストに含まれる、すべての健全なコントロールプレーンノードにトラフィックを分配します。apiserverへのヘルスチェックはkube-apiserverがリッスンするポート(デフォルト値: :6443
)に対する、TCPチェックです。
クラウド環境では、IPアドレスを直接使うことは推奨されません。
ロードバランサーは、apiserverポートで、全てのコントロールプレーンノードと通信できなければなりません。また、リスニングポートに対する流入トラフィックも許可されていなければなりません。
HAProxyをロードバランサーとして使用することができます。
ロードバランサーのアドレスは、常にkubeadmのControlPlaneEndpoint
のアドレスと一致することを確認してください。
ロードバランサーに、最初のコントロールプレーンノードを追加し、接続をテストする:
nc -v LOAD_BALANCER_IP PORT
残りのコントロールプレーンノードを、ロードバランサーのターゲットグループに追加します。
1台のマシンから全てのノードをコントロールしたいのであれば、SSHが必要です。
システム内の全ての他のノードにアクセスできるメインデバイスで、ssh-agentを有効にします
eval $(ssh-agent)
SSHの秘密鍵を、セッションに追加します:
ssh-add ~/.ssh/path_to_private_key
正常に接続できることを確認するために、ノード間でSSHします。
ノードにSSHする際は、必ず-A
フラグをつけます:
ssh -A 10.0.0.7
ノードでsudoするときは、SSHフォワーディングが動くように、環境変数を引き継ぎます:
sudo -E -s
最初のコントロールプレーンノードで、kubeadm-config.yaml
という設定ファイルを作成します:
apiVersion: kubeadm.k8s.io/v1beta1
kind: ClusterConfiguration
kubernetesVersion: stable
apiServer:
certSANs:
- "LOAD_BALANCER_DNS"
controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT"
kubernetesVersion
には使用するKubernetesのバージョンを設定します。この例ではstable
を使用しています。controlPlaneEndpoint
はロードバランサーのアドレスかDNSと、ポートに一致する必要があります。ノードがきれいな状態であることを確認します:
sudo kubeadm init --config=kubeadm-config.yaml
このような出力がされます:
...
You can now join any number of machines by running the following on each node
as root:
kubeadm join 192.168.0.200:6443 --token j04n3m.octy8zely83cy2ts --discovery-token-ca-cert-hash sha256:84938d2a22203a8e56a787ec0c6ddad7bc7dbd52ebabc62fd5f4dbea72b14d1f
この出力をテキストファイルにコピーします。あとで、他のコントロールプレーンノードをクラスターに参加させる際に必要になります。
Weave CNIプラグインをapplyします:
kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
以下のコマンドを入力し、コンポーネントのPodが起動するのを確認します:
kubectl get pod -n kube-system -w
証明書ファイルを最初のコントロールプレーンノードから残りのノードにコピーします:
以下の例では、CONTROL_PLANE_IPS
を他のコントロールプレーンノードのIPアドレスで置き換えます。
USER=ubuntu # 変更可能
CONTROL_PLANE_IPS="10.0.0.7 10.0.0.8"
for host in ${CONTROL_PLANE_IPS}; do
scp /etc/kubernetes/pki/ca.crt "${USER}"@$host:
scp /etc/kubernetes/pki/ca.key "${USER}"@$host:
scp /etc/kubernetes/pki/sa.key "${USER}"@$host:
scp /etc/kubernetes/pki/sa.pub "${USER}"@$host:
scp /etc/kubernetes/pki/front-proxy-ca.crt "${USER}"@$host:
scp /etc/kubernetes/pki/front-proxy-ca.key "${USER}"@$host:
scp /etc/kubernetes/pki/etcd/ca.crt "${USER}"@$host:etcd-ca.crt
scp /etc/kubernetes/pki/etcd/ca.key "${USER}"@$host:etcd-ca.key
scp /etc/kubernetes/admin.conf "${USER}"@$host:
done
注意: 上のリストにある証明書だけをコピーしてください。kubeadmが、参加するコントロールプレーンノード用に、残りの証明書と必要なSANの生成を行います。間違って全ての証明書をコピーしてしまったら、必要なSANがないため、追加ノードの作成は失敗するかもしれません。
scp
を使用する手順で作成したファイルを移動します:
USER=ubuntu # 変更可能
mkdir -p /etc/kubernetes/pki/etcd
mv /home/${USER}/ca.crt /etc/kubernetes/pki/
mv /home/${USER}/ca.key /etc/kubernetes/pki/
mv /home/${USER}/sa.pub /etc/kubernetes/pki/
mv /home/${USER}/sa.key /etc/kubernetes/pki/
mv /home/${USER}/front-proxy-ca.crt /etc/kubernetes/pki/
mv /home/${USER}/front-proxy-ca.key /etc/kubernetes/pki/
mv /home/${USER}/etcd-ca.crt /etc/kubernetes/pki/etcd/ca.crt
mv /home/${USER}/etcd-ca.key /etc/kubernetes/pki/etcd/ca.key
mv /home/${USER}/admin.conf /etc/kubernetes/admin.conf
この手順で、/etc/kubernetes
フォルダーに必要な全てのファイルが書き込まれます。
kubeadm init
を最初のノードで実行した際に取得したjoinコマンドを使って、このノードでkubeadm join
を開始します。このようなコマンドになるはずです:
sudo kubeadm join 192.168.0.200:6443 --token j04n3m.octy8zely83cy2ts --discovery-token-ca-cert-hash sha256:84938d2a22203a8e56a787ec0c6ddad7bc7dbd52ebabc62fd5f4dbea72b14d1f --experimental-control-plane
--experimental-control-plane
フラグが追加されています。このフラグは、コントロールプレーンノードのクラスターへの参加を自動化します。以下のコマンドをタイプし、コンポーネントのPodが起動するのを確認します:
kubectl get pod -n kube-system -w
これらのステップを、残りのコントロールプレーンノードに対して繰り返します。
以下のファイルをetcdクラスターのどれかのノードからこのノードへコピーしてください:
export CONTROL_PLANE="ubuntu@10.0.0.7"
+scp /etc/kubernetes/pki/etcd/ca.crt "${CONTROL_PLANE}":
+scp /etc/kubernetes/pki/apiserver-etcd-client.crt "${CONTROL_PLANE}":
+scp /etc/kubernetes/pki/apiserver-etcd-client.key "${CONTROL_PLANE}":
CONTROL_PLANE
の値を、このマシンのuser@host
で置き換えます。以下の内容で、kubeadm-config.yaml
という名前の設定ファイルを作成します:
apiVersion: kubeadm.k8s.io/v1beta1
kind: ClusterConfiguration
kubernetesVersion: stable
apiServer:
certSANs:
- "LOAD_BALANCER_DNS"
controlPlaneEndpoint: "LOAD_BALANCER_DNS:LOAD_BALANCER_PORT"
etcd:
external:
endpoints:
- https://ETCD_0_IP:2379
- https://ETCD_1_IP:2379
- https://ETCD_2_IP:2379
caFile: /etc/kubernetes/pki/etcd/ca.crt
certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt
keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key
ここで、積み重なったetcdと外部etcdの違いは、kubeadmコンフィグのetcd
にexternal
フィールドを使用していることです。積み重なったetcdトポロジーの場合、これは自動で管理されます。
テンプレート内の以下の変数を、クラスターに合わせて適切な値に置き換えます:
LOAD_BALANCER_DNS
LOAD_BALANCER_PORT
ETCD_0_IP
ETCD_1_IP
ETCD_2_IP
kubeadm init --config kubeadm-config.yaml
をこのノードで実行します。
表示されたjoinコマンドを、あとで使うためにテキストファイルに書き込みます。
Weave CNIプラグインをapplyします:
kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$(kubectl version | base64 | tr -d '\n')"
残りのコントロールプレーンノードを参加させるために、こちらの手順に従います。ローカルetcdメンバーが作られないことを除いて、積み重なったetcdの構築と同じ手順です。
まとめると:
--experimental-control-plane
フラグを加えたものを使って、それぞれのコントロールプレーンノードを参加させます。Podネットワークをインストールするには、こちらの手順に従ってください。master設定ファイルで提供したPod CIDRのどれかに一致することを確認します。
kubeadm init
コマンドから返されたコマンドを利用して、workerノードをクラスターに参加させることが可能です。workerノードには、--experimental-control-plane
フラグを追加する必要はありません。
このページは役に立ちましたか?
Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on Stack Overflow. Open an issue in the GitHub repo if you want to report a problem or suggest an improvement.