kubeadmで単一マスタのクラスタ構築（参考訳：v1.10)

このドキュメントについて

これはv1.10の古いドキュメント)に対する参考訳です。正確には先のページの更新版に対する翻訳（6月上旬時点）です。v1.11へのバージョンアップに伴い手順が一部変わりました。現行バージョンとは一部手順が異なるものの、見直すこともあるかと思い、残しておきます。

なお、現行バージョンのドキュメントは v1.11のドキュメント をご覧ください。

Creating a single master cluster with kubeadm

kubeadm は Kubernetes クラスタを構築するのに役立つベスト・プラクティスのツールキットであり、簡単、合理的、安全かつ拡張可能な手法です。また、 ブートストラップ・トークン(Bootstrap Tokens) も管理するため、クラスタのアップグレードやダウングレードをサポートします。

kubeadm はKubernetes 適合試験 の最小クラスタ環境をセットアップするためであり、クラスタ構成の基盤に必要な他のアドオンは範囲外です。

設計上、ネットワーク機能のソリューションはインストールされません。そのため、自分自身で kubectl apply を用いサードパーティ製の CNI 互換ネットワーク機能ソリューションのインストールが必要です。

kubeadm を実行するマシン環境の種類は問題としていません。Linux ノート PC 、仮想マシン、物理・クラウドサーバや Raspberry Pi でも動作するでしょう。そのため、kubeadm は様々な種類のプロビジョニング・システム（例： Terraform 、 Ansible 等）と統合できるでしょう。

Kubeadm は新規ユーザが Kubernetes を試し始めるために、可能な限り初回から、最も簡単な手法となるよう設計されています。また、既存のユーザがアプリケーションのテストや、クラスタの簡単な組み上げだけでなく、広範囲に亘るインストール用ツールや、他とのエコシステムを築き上げるためです。

kubeadm をオペレーティングシステムにインストールするのは非常に簡単です。そのために deb あるいは rpm パッケージのインストール緒wサポートしています。kubeadm 用 SIG の対応としては、SIG クラスタ・ライフサイクル では構築済みのパッケージが提供されているだけでなく、その他の OS についても提供されています。

kubeadm 成熟度

領域	成熟度
コマンドライン UX	beta
実装	beta
設定ファイル API	alpha
セルフ・ホスティング	alpha
kubeadm アルファ・コマンド	alpha
CoreDNS	alpha
DynamicKubeletConfig	alpha

kubeadm の機能大半は Beta ですが、2018 年内には間もなく 一般利用可能 (GA) に卒業予定です。これらには活発に開発が進められているセルフ・ホスティングや設定ファイル API をいった複数のサブ機能を含みます。クラスタ構築の実装は、ツールの進化によって若干の変化があるかもしれません。しかし、大部分の実装はおおよそ安定しています。kubeadm alpha 配下で定義されているコマンドは、アルファ・レベルのサポートです。

サポート期間

Kubernetes のリリースは通常９ヶ月間サポートされており、何らかのバグやセキュリティ問題が発見されれば、リリース・ブランチから分岐して、定期的にパッチを提供します。以下は Kubernetes の最新リリースとサポート期間であり、 kubeadm にも適用されます。

Kubernetes バージョン	リリース月	提供終了(End-of-life-month)
v1.6.x	2017年3月	2017年12月
v1.7.x	2017年6月	2018年3月
v1.8.x	2017年9月	2018年6月
v1.9.x	2017年12月	2018年9月
v1.10.x	2018年3月	2018年12月

準備

• dev/rpm 互換 OS を実行可能な１つまたは複数のマシン。例： Ubuntu または CentOS 。
• マシンごとに 2 GB 以上のメモリ（動作アプリケーションが小さければ少なくても可能）
• マスタは 2 CPU 以上
• クラスタ内の全てのマシン間で完全なネットワーク接続性がある（パブリックまたはプライベート・ネットワークでも）

目標

• マシン上に安全な Kubernetes クラスタをインストール
• クラスタ上に Pod ネットワークをインストールするので、Pod 間で相互通信できる

手順

kubeadm をホスト上にインストール

kubeadm のインストール をご覧ください。

メモ: 既に kubeadm をインストールしている場合は、apt-get update && apt-get upgrade か yum update を実行し、kubeadm の最新版を入手します。

kubelet は数秒ごとに再起動するため、kubeadm が次に何をすべきか伝えるためクラッシュループ (crashloop) で待機します。クラッシュループは予測可能であり、正常ですから、次のステップに進めば、kubelet は通常通り動作します。

マスタの初期化

マスタとはコントロール・プレーン・コンポーネントを実行するためのマシンであり、 etcd（クラスタのデータベース）と API サーバ（kubectl CLI と通信）を含みます。

マスタを初期化するには、まずインストールしたい pod ネットワーク・プラグインを選択し、 kubeadm でクラスタを初期化するために必要なパラメータを確認します。kubeadm をインストールしたマシンの中から１つを選び、次のように実行します。

kubeadm init

メモ:

• kubeadm init で指定可能なフラグの詳細を知りたい場合は、 [kubeadm リファレンス・ガイド] (Overview of kubeadm - Kubernetes) をご覧ください。あるいはフラグではなく 設定ファイル でも指定できます。
• 次のステップで Pod ネットワーク・プラグインを選ぶ必要があります。選択したサードパーティ製プロバイダによって依存しますが、特定のプロバイダ固有のものとして --pod-network-cidr があります。ここでは kubeadm init で指定したフラグによって、特別な指定が必要になる場合もありますのでご注意ください。
• 特に指定がなければ、kubeadm はマスタの IP を広報(advertise)するために、デフォルト・ゲートウェイのネットワーク・インターフェースを使います。異なったネットワーク・インタフェースを指定する場合は、 kubeadm init の引数として --apiserver-advertise-address=<ip-アドレス> を指定します。IPv6 Kubernetes クラスタで IPv6 アドレスで展開したい場合は、 IPv6 を --apiserver-advertise-address=fd00::101 のように指定する必要があります。
• もしもコントロール・プレーン・コンポーネントや etcd サーバの死活監視をするため、コントロール・プレーン・コンポーネントにオプションで IPv6 を割り当てたい場合は、 こちら のドキュメントに記載の拡張引数を指定する必要があります。
• kubeadm init の初回実行時、マシンで Kubernetes を実行するかどうか準備が整っているかどうか一連の事前確認を行います。これにより警告やエラーが表示するかもしれません。その場合はクラスタ・データベースやコントロール・プレーン・コンポーネントのダウンロードやインストールをします。これには数分ほどかかる場合もあります。
• v1.6 から v1.7 へのアップグレードを試みていない限り、ティア・ダウン（Tear Down）のために kubeadm init を実行できません。詳しくは ティア・ダウン. をご覧ください。

出力は以下のようなものでしょう:

[init] Using Kubernetes version: v1.8.0
[init] Using Authorization modes: [Node RBAC]
[preflight] Running pre-flight checks
[kubeadm] WARNING: starting in 1.8, tokens expire after 24 hours by default (if you require a non-expiring token use --token-ttl 0)
[certificates] Generated ca certificate and key.
[certificates] Generated apiserver certificate and key.
[certificates] apiserver serving cert is signed for DNS names [kubeadm-master kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 10.138.0.4]
[certificates] Generated apiserver-kubelet-client certificate and key.
[certificates] Generated sa key and public key.
[certificates] Generated front-proxy-ca certificate and key.
[certificates] Generated front-proxy-client certificate and key.
[certificates] Valid certificates and keys now exist in "/etc/kubernetes/pki"
[kubeconfig] Wrote KubeConfig file to disk: "admin.conf"
[kubeconfig] Wrote KubeConfig file to disk: "kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "scheduler.conf"
[controlplane] Wrote Static Pod manifest for component kube-apiserver to "/etc/kubernetes/manifests/kube-apiserver.yaml"
[controlplane] Wrote Static Pod manifest for component kube-controller-manager to "/etc/kubernetes/manifests/kube-controller-manager.yaml"
[controlplane] Wrote Static Pod manifest for component kube-scheduler to "/etc/kubernetes/manifests/kube-scheduler.yaml"
[etcd] Wrote Static Pod manifest for a local etcd instance to "/etc/kubernetes/manifests/etcd.yaml"
[init] Waiting for the kubelet to boot up the control plane as Static Pods from directory "/etc/kubernetes/manifests"
[init] This often takes around a minute; or longer if the control plane images have to be pulled.
[apiclient] All control plane components are healthy after 39.511972 seconds
[uploadconfig] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[markmaster] Will mark node master as master by adding a label and a taint
[markmaster] Master master tainted and labelled with key/value: node-role.kubernetes.io/master=""
[bootstraptoken] Using token: <token>
[bootstraptoken] Configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstraptoken] Configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstraptoken] Creating the "cluster-info" ConfigMap in the "kube-public" namespace
[addons] Applied essential addon: kube-dns
[addons] Applied essential addon: kube-proxy

Your Kubernetes master has initialized successfully!

To start using your cluster, you need to run (as a regular user):

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  http://kubernetes.io/docs/admin/addons/

You can now join any number of machines by running the following on each node
as root:

  kubeadm join --token <token> <master-ip>:<master-port> --discovery-token-ca-cert-hash sha256:<hash>

root 以外のユーザで kubectl を動作させるためには、以下のコマンドの実行が必要になるでしょう（こちらは kubeadm init の出力にも含まれます ）。

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

あるいは、 root ユーザであれば、こちらのコマンドを実行します:

export KUBECONFIG=/etc/kubernetes/admin.conf

kubeadm init の出力から kubeadm join コマンドに関する記録をします。しばらくした後に必要となるかもしれません。

トークンはマスタと参加ノード間で認証するために使います。トークンには、ここではシークレットを含みます。クラスタに認証ノードを誰でも追加できるものなので、安全な場所に保管します。これらトークンの一覧表示、作成、削除は kubeadm token コマンドを持ちます。詳しい情報は リファレンス・ガイド をご覧ください。

pod ネットワークのインストール

ポットがお互いに通信できるようにするためには pod ネットワーク・アドオンのインストールが 必須 です。

あらゆるアプリケーションを展開する前に、ネットワークの展開が必要です。そのため、 kube-dns という内部のヘルパー・サイビスはネットワークがインストールされるまで起動しません。kubeadm がサポートするのはコンテナ・ネットワーク・インターフェース (CNI) をベースとしたネットワークのみです（また、kubenetはサポートしません）。

いくつかのプロジェクトでは Kubernetes ポッド・ネットワークに CNI が使われたものを提供しますが、またいくつかは ネットワーク・ポリシー もサポートします。アドオン・ページ をご覧いただくと、利用可能なネットワーク・アドオンの完全な一覧をご覧いただけます。IPv6 サポートは CNI v0.6.0　で追加されました。 CNI bridge と local-ipam がサポートされているのは、1.9 における IPv6 ネットワーク・プラグインです。

メモ: kubeadm はより安全なクラスタをセットアップするため、標準で RBAC の利用を強制します。ネットワーク・マニフェストで RBAC のサポートを選択しているかどうか、確認してください。

ポッド・ネットワークのアドオンは、以下のコマンドでインストールできます:

kubectl apply -f <add-on.yaml>

メモ: クラスタごとにインストールできるポッド・ネットワークは １つだけ です。

サードパーティ製ポッド・ネットワーク・プロバイダのタブをクリックすると、インストール手順を表示します。

Calico

Calico の詳細は、 Quickstart for Calico on Kubernetes、 Installing Calico for policy and networking、そして関連リソースをご覧ください。

メモ:

• ネットワーク・ポリシーを正常に動かすためには、 --pod-network-cidr=192.168.0.0/16 を kubeadm init で指定する必要があります。
• Calico が動作するのは amd64 のみです。

kubectl apply -f https://docs.projectcalico.org/v3.1/getting-started/kubernetes/installation/hosted/rbac-kdd.yaml
kubectl apply -f https://docs.projectcalico.org/v3.1/getting-started/kubernetes/installation/hosted/kubernetes-datastore/calico-networking/1.7/calico.yaml

{{% /tab %}}
{{% tab name="Canal" %}}
Canal はポリシーのために Calico を、ネットワーク機能のために Flannel を使います。Calico ドキュメントを参照するには、 official getting started guide をご覧ください。

メモ:

• Canal を正常に動かすためには、 --pod-network-cidr=10.244.0.0/16 を kubeadm init で指定する必要があります。
• Canal が動作するのは amd64 のみです。

kubectl apply -f https://docs.projectcalico.org/v3.1/getting-started/kubernetes/installation/hosted/canal/rbac.yaml
kubectl apply -f https://docs.projectcalico.org/v3.1/getting-started/kubernetes/installation/hosted/canal/canal.yaml

Flannel

メモ:

• flannel を正常に動かすためには --pod-network-cidr=10.244.0.0/16 を kubeadm init で指定する必要があります。
• flannel が動作するのは amd64、 arm、 arm64、ppc64le ですが、amd64 以外のプラットフォームで動作する場合は、マニフェストを手動でダウンロードし、 amd64 の部分を適切なプラットフォームに書き換える必要があります。
• 実行時に /proc/sys/net/bridge/bridge-nf-call-iptables を 1 にセットすると、 sysctl net.bridge.bridge-nf-call-iptables=1 によって IPv4 トラフィックを iptables のチェーンにブリッジします。これはいくつかの CNI プラグインを実行するために必要であり、より詳しい情報は こちら をご覧ください。

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/v0.10.0/Documentation/kube-flannel.yml

• flannel に関するより詳しい情報は、こちら をご覧ください。

Kube-router

実行時に /proc/sys/net/bridge/bridge-nf-call-iptables を 1 にセットすると、 sysctl net.bridge.bridge-nf-call-iptables=1 によって IPv4 トラフィックを iptables のチェーンにブリッジします。これはいくつかの CNI プラグインを実行するために必要であり、より詳しい情報は こちら をご覧ください。

Kube-router はノードに対して pod CIDR を割り当てるため、 kube-controller-manager に依存します。そのため、 kubeadm init で --pod-network-cidr フラグの指定が必要です。

Kube-router が提供するのはポッド・ネットワーク機能、ネットワーク・ポリシー、サービス・プロキシをベースと下高性能 IP 仮想サーバ（IPVS）/Linux 仮想サーバ(LVS)です。

kubeadm で kube-router に対応した Kubernetes クラスタをセットアップするための詳細については、公式の セットアップ・ガイド をご覧ください。

Romana

実行時に /proc/sys/net/bridge/bridge-nf-call-iptables を 1 にセットすると、 sysctl net.bridge.bridge-nf-call-iptables=1 によって IPv4 トラフィックを iptables のチェーンにブリッジします。これはいくつかの CNI プラグインを実行するために必要であり、より詳しい情報は こちら をご覧ください。

公式の Romana セットアップ・ガイドは こちら です。

メモ: Romana が動作するのは amd64 のみです

kubectl apply -f https://raw.githubusercontent.com/romana/romana/master/containerize/specs/romana-kubeadm.yml

Weave Net

実行時に /proc/sys/net/bridge/bridge-nf-call-iptables を 1 にセットすると、 sysctl net.bridge.bridge-nf-call-iptables=1 によって IPv4 トラフィックを iptables のチェーンにブリッジします。これはいくつかの CNI プラグインを実行するために必要であり、より詳しい情報は こちら をご覧ください。

公式の Weave Net セットアップ・ガイドは こちら です。

メモ: Weave Net は追加設定を必要とせず amd64、 arm、 arm64、 ppc64le で動作します。
Weave Net はデフォルトではヘアピン・モード(hairpin mode)です。これにより、Pod は PodIP を知らなくても自身のサービス IP アドレスを経由してアクセスできます。

export kubever=$(kubectl version | base64 | tr -d '
')
kubectl apply -f "https://cloud.weave.works/k8s/net?k8s-version=$kubever"

ポッド・ネットワークをインストールしたら、 kubectl get pods --all-namespaces の出力から kube-dns ポッドが稼働しているかどうか確認可能になります。そして、kube-dns ポッドが起動・実行したら、ノードの追加が可能になります。

もしもネットワーク上で kube-dns が実行中の状態でなければ、 トラブルシューティング・ドキュメント をご覧ください。

マスタの分離（isolation）

デフォルトでは、セキュリティ上の理由により、クラスタはマスタ上にポッドをスケジュールしません。もしもマスタ上にポッドをスケジュールできるようにしたい場合、例えば、１台のマシンで 開発用 Kubernetes クラスタを動作させたい場合は、次のように実行します:

kubectl taint nodes --all node-role.kubernetes.io/master-

実行結果は次のようになります:

node "test-01" untainted
taint key="dedicated" and effect="" not found.
taint key="dedicated" and effect="" not found.

これはマスタ・ノードを含むあらゆるノードから node-role.kubernetes.io/master テイントを削除するもので、これにより、スケジューラはポッドをどこでもスケジュール可能にします。

ノードの追加(Joining)

ノードとはどこでワークロード（コンテナ、ポッド等）を実行するかです。クラスタの各マシンで新しいノードを追加するには、次のようにします:

• マシンに SSH
• root になる (例: sudo su -)
• kubeadm init の出力結果のコマンドを実行。実行例:

kubeadm join --token <token> <master-ip>:<master-port> --discovery-token-ca-cert-hash sha256:<hash>

{{< note >}}
メモ: IPv6 タプルを <master-ip>:<master-port> で指定するには、 [fd00::101]:2073 のように IPv6 アドレスを角括弧で囲む必要があります。
{{< /note >}}

出力結果は次のようなものです:

[preflight] Running pre-flight checks
[discovery] Trying to connect to API Server "10.138.0.4:6443"
[discovery] Created cluster-info discovery client, requesting info from "https://10.138.0.4:6443"
[discovery] Requesting info from "https://10.138.0.4:6443" again to validate TLS against the pinned public key
[discovery] Cluster info signature and contents are valid and TLS certificate validates against pinned roots, will use API Server "10.138.0.4:6443"
[discovery] Successfully established connection with API Server "10.138.0.4:6443"
[bootstrap] Detected server version: v1.8.0
[bootstrap] The server supports the Certificates API (certificates.k8s.io/v1beta1)
[csr] Created API client to obtain unique certificate for this node, generating keys and certificate signing request
[csr] Received signed certificate from the API server, generating KubeConfig...

Node join complete:
* Certificate signing request sent to master and response
  received.
* Kubelet informed of new secure connection details.

Run 'kubectl get nodes' on the master to see this machine join.

マスタ上で実行すると、数秒後に kubectl get nodes の出力結果から対象ノードを確認できるでしょう。

(オプション) マスタ以外のマシンからクラスタを制御

kubectl を他のコンピュータ（例: ノートPC）で取得して、クラスタと通信できるようにするには、管理用 kubeconfig ファイルを、マスタから対象マシンに対して次のようにコピーする必要があります。

scp root@<master ip>:/etc/kubernetes/admin.conf .
kubectl --kubeconfig ./admin.conf get nodes

メモ:

• 先の例は root での SSH アクセスが可能である場合のものです。そうでなければ、 admin.conf を他のアクセス可能なユーザにコピーし、他のユーザで scp を使います。
• admin.conf ファイルはユーザに対し、クラスタを超えて スーパーユーザ 特権をあたえます。このファイルは慎重に扱うべきです。通常のユーザでは、ホワイトリスト権限をあたえたユニークな認証情報（クレデンシャル）を生成するのを推奨します。そのためには kubeadm alpha phase kubeconfig user --client-name <CN>コマンドを実行します。このコマンドによって KubeConfig ファイルの情報を標準出力し、出力結果をファイルに保存し、ユーザに与えられます。以降、ホワイトリスト権限は kubectl create (cluster)rolebinding を用います。

(オプション) API サーバをローカルホストにプロキシ

クラスタ外から API サーバにアクセスしたい場合は、kubectl proxy が使えます:

scp root@<master ip>:/etc/kubernetes/admin.conf .
kubectl --kubeconfig ./admin.conf proxy

これでローカルから API サーバには http://localhost:8001/api/v1 でアクセスできます。

ティア・ダウン(Tear down)

kubeadm で行ったことを取り消したい場合、まず ノードをドレーン（排出；drain） し、ノードを停止する前にノードが空なのを確認します。

マスタと適切な認証情報で通信し、実行します:

kubectl drain <node name> --delete-local-data --force --ignore-daemonsets
kubectl delete node <node name>

それから、削除するノード上で、kubeadm がインストールした状態をリセットします:

kubeadm reset

もしもやり直したい場合は、単純に kubeadm init や kubeadm join に適切な引数を付けるだけです。

詳しいオプションや追加情報については
kubeadm reset コマンド をご覧ください。

kubeadm クラスタのアップグレード

kubeadm クラスタのアップグレード手順は、以下の通り利用できます:

• 1.6 to 1.7 upgrades
• 1.7.x to 1.7.y upgrades
• 1.7 to 1.8 upgrades
• 1.8.x to 1.8.y upgrades
• 1.8 to 1.9 upgrades/downgrades
• 1.9.x to 1.9.y upgrades
• 1.9.x to 1.9.y HA cluster upgrades

他のアドオンを探す

アドオンの一覧 をご覧いただくと、ログ記録、モニタリング、ネットワーク・ポリシー、可視化、Kubernetes クラスタの管理する他のアドオンを探せます。

次はどうしますか

• Kubeadmの高度な使い方を学ぶには kubeadm リファレンス・ドキュメント をご覧ください
• Kubernetesの 概念 と kubectl について学ぶ
• ローテーションを設定する。そのために logrotate を使う。Docker を使っている場合は、Docker デーモンのログ・ローテーション設定は次のように行えます: --log-driver=json-file --log-opt=max-size=10m --log-opt=max-file=5 。詳しくは Docker デーモンの設定変更とトラブルシュート をご覧ください。

フィードバック

• kubeadm をサポートする Slack Channel:
  #kubeadm
• General SIG Cluster Lifecycle Development Slack Channel:
  #sig-cluster-lifecycle
• SIG Cluster Lifecycle SIG information
• SIG Cluster Lifecycle Mailing List:
  kubernetes-sig-cluster-lifecycle
• kubeadm Github issue tracker

バージョンずれに関するポリシー

kubeadm CLI ツールのバージョン vX.Y は、コントロール・プレーンのバージョン vX.Y または vX.(Y-1) でもデプロイ可能な場合があります。また、kubeadm CLI vX.Y は、既存の kubeadm バージョン vX.(Y-1)で作成した場合はアップロードできます。

将来的に期限切れで利用できなくなる kubeadm CLI vX.Y は、 vX.(Y+1) クラスタにデプロイできない場合があります。

例: kubeadm v1.8 は v1.7 と v1.8 クラスタの両方にデプロイでき、v1.7 kubeadm で作成したクラスタは v1.8 にアップグレードできる。

また、kubeletes と コントロール・プレーン間のバージョンずれに関しては インストール・ガイド をご確認ください。

複数のプラットフォームで動作する kubeadm

kubeadm の deb/rpm パッケージとバイナリを構築している対象は、amd64、 arm (32-bit)、 arm64、 ppc64le、s390x、そして以下の マルチプラットフォーム提案 です。

ネットワーク・プロバイダによっては各プラットフォームに対応した解決策を提供している場合があります。先ほどのネットワーク・プロバイダと相談するか、選択したプラットフォームがサポートしているプロバイダが指示するドキュメントをご覧ください。

制限事項

ご注意ください: kubeadm の開発は進行中であり、用途によっては制限がある場合もあります。

1. ここで作成したクラスタはマスタが１つだけで、１つの etcd データベースを動かしています。つまり、もしもマスタで障害が起こればデータを失うかもしれませんし、場合によってはゼロから環境再構築の必要が出てくるかもしれません。HA サポート（複数の ecd サーバ、複数の API サーバ等）の追加により、kubeadm は動作し続けるようになります。

   回避方法: 通常は etcd をバックアップ 。マスタ上の kubeadm が設定する etcd データ・ディレクトリは /var/lib/etcd です。

トラブルシューティング

kubeadm を動かして何かおかしければ、 トラブルシューティング・ドキュメント をご覧ください。