kubeadmをセットアップしてみたが、いつも通りハマる
TL;DR
- AWS EC2のCentOS7上にkubeadmでk8s環境を構築
- CGROUPの問題でkubeletが正常に稼動していないせいで、はまった
/etc/systemd/sytem内のkubelet設定ファイルを削除し、最初からやり直したら成功
イントロ
k8s超初心者の自分（dockerは頻繁に使っていて、swarmも使っているが、k8sはminikubeをちょっと試したことがある程度）が、分散環境でしっかりk8sを使っていこうと思い、kubeadmに手を出してみました。
昔から、"実験"やら"演習"やら"構築"やら、そういったことをすると、必ずハマってきた自分です。 今回も、盛大にハマりました。正常運転です。
構築に関してまず参考にしたのが、こちらのQiitaの記事。
環境、OS、docker、kubeletのアプリのバージョンがすべて同じです（なのにハマるとかすごい）。
kubeadm initでエラー
masterのkubeadm initの手前までは、手順通りに進み、kubeadm initで、エラー。
[root@kube-master centos]# kubeadm init --pod-network-cidr=10.244.0.0/16 --apiserver-advertise-address=172.31.15.45
[init] using Kubernetes version: v1.11.2
[preflight] running pre-flight checks
I0811 02:17:36.944275 6222 kernel_validator.go:81] Validating kernel version
I0811 02:17:36.944356 6222 kernel_validator.go:96] Validating kernel config
[preflight/images] Pulling images required for setting up a Kubernetes cluster
[preflight/images] This might take a minute or two, depending on the speed of your internet connection
[preflight/images] You can also perform this action in beforehand using 'kubeadm config images pull'
[kubelet] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[preflight] Activating the kubelet service
[certificates] Generated ca certificate and key.
[certificates] Generated apiserver certificate and key.
[certificates] apiserver serving cert is signed for DNS names [kube-master kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 172.31.15.45]
[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] Generated etcd/ca certificate and key.
[certificates] Generated etcd/server certificate and key.
[certificates] etcd/server serving cert is signed for DNS names [kube-master localhost] and IPs [127.0.0.1 ::1]
[certificates] Generated etcd/peer certificate and key.
[certificates] etcd/peer serving cert is signed for DNS names [kube-master localhost] and IPs [172.31.15.45 127.0.0.1 ::1]
[certificates] Generated etcd/healthcheck-client certificate and key.
[certificates] Generated apiserver-etcd-client certificate and key.
[certificates] valid certificates and keys now exist in "/etc/kubernetes/pki"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/admin.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/kubelet.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/controller-manager.conf"
[kubeconfig] Wrote KubeConfig file to disk: "/etc/kubernetes/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 might take a minute or longer if the control plane images have to be pulled
Unfortunately, an error has occurred:
timed out waiting for the condition
This error is likely caused by:
- The kubelet is not running
- The kubelet is unhealthy due to a misconfiguration of the node in some way (required cgroups disabled)
- No internet connection is available so the kubelet cannot pull or find the following control plane images:
- k8s.gcr.io/kube-apiserver-amd64:v1.11.2
- k8s.gcr.io/kube-controller-manager-amd64:v1.11.2
- k8s.gcr.io/kube-scheduler-amd64:v1.11.2
- k8s.gcr.io/etcd-amd64:3.2.18
- You can check or miligate this in beforehand with "kubeadm config images pull" to make sure the images
are downloaded locally and cached.
If you are on a systemd-powered system, you can try to troubleshoot the error with the following commands:
- 'systemctl status kubelet'
- 'journalctl -xeu kubelet'
Additionally, a control plane component may have crashed or exited when started by the container runtime.
To troubleshoot, list all containers using your preferred container runtimes CLI, e.g. docker.
Here is one example how you may list all Kubernetes containers running in docker:
- 'docker ps -a | grep kube | grep -v pause'
Once you have found the failing container, you can inspect its logs with:
- 'docker logs CONTAINERID'
couldn't initialize a Kubernetes cluster
kubeletが、configの設定にミスってるのか、正常に動いていないよ、とのこと。
kubeletが動いていない
kubeletって何だっけ、と思い、確認。
各ノードが協調動作するためのエージェントデーモンですね。 workerのkubeletが、masterのAPI serverと通信する事で、クラスタが協調動作できると。
ただ、この図を見る限り、masterでは動かず、workerのみで動くもののように見えますが、自分が参考にしたページでは、 masterにもインストールして稼動させていますね…。 masterにもkubeletが必要なのかどうかが気になりますが、少し調べた程度では答えが見つからず…。
とりあえず気を取り直して、一応、workerでkubeletが動いているかを確認。
[root@kube-node1 centos]# systemctl status kubelet
● kubelet.service - kubelet: The Kubernetes Node Agent
Loaded: loaded (/etc/systemd/system/kubelet.service; enabled; vendor preset: disabled)
Drop-In: /etc/systemd/system/kubelet.service.d
└─10-kubeadm.conf, 90-local-extras.conf
Active: activating (auto-restart) (Result: exit-code) since Sat 2018-08-11 03:33:01 UTC; 7s ago
Docs: https://kubernetes.io/docs/
Process: 1811 ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS (code=exited, status=255)
Main PID: 1811 (code=exited, status=255)
Aug 11 03:33:01 kube-node1 systemd[1]: kubelet.service: main process exited, code=exited, status=255/n/a
Aug 11 03:33:01 kube-node1 systemd[1]: Unit kubelet.service entered failed state.
Aug 11 03:33:01 kube-node1 systemd[1]: kubelet.service failed.
動いていない。
ここでtwitterで、swapをoffにするといいことがあるかも、と情報をもらいましたが、既にswapをoffにする設定はしています。
念のため、swapoff -aでoffにしてやり直しても、状況は変わらず。
ちなみに、masterにもなぜかkubeletをインストール&稼動させた気がするので、そちらではどうなっているのかを確認。
[root@kube-master centos]# systemctl status kubelet
● kubelet.service - kubelet: The Kubernetes Node Agent
Loaded: loaded (/etc/systemd/system/kubelet.service; enabled; vendor preset: disabled)
Drop-In: /etc/systemd/system/kubelet.service.d
└─10-kubeadm.conf, 90-local-extras.conf
Active: active (running) since Sat 2018-08-11 03:27:13 UTC; 17min ago
Docs: https://kubernetes.io/docs/
Main PID: 21221 (kubelet)
CGroup: /system.slice/kubelet.service
└─21221 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --cgroup-driver=systemd --cni-bin-dir=/opt/cni/bi...
Aug 11 03:44:38 kube-master kubelet[21221]: W0811 03:44:38.522146 21221 cni.go:172] Unable to update cni config: No networks found in /etc/cni/net.d
Aug 11 03:44:38 kube-master kubelet[21221]: E0811 03:44:38.522570 21221 kubelet.go:2110] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is n...ig uninitialized
Aug 11 03:44:42 kube-master kubelet[21221]: I0811 03:44:42.179948 21221 kubelet_node_status.go:269] Setting node annotation to enable volume controller attach/detach
Aug 11 03:44:42 kube-master kubelet[21221]: I0811 03:44:42.482381 21221 kuberuntime_manager.go:513] Container {Name:kube-apiserver Image:k8s.gcr.io/kube-apiserver-amd64:v1.11.2 Command:[kube-apiserver --author...es/pki/ca.crt --
Aug 11 03:44:42 kube-master kubelet[21221]: I0811 03:44:42.482486 21221 kuberuntime_manager.go:757] checking backoff for container "kube-apiserver" in pod "kube-apiserver-kube-master_kube-system(7a1b9f5fe804e9...9abbbbd1143041)"
Aug 11 03:44:42 kube-master kubelet[21221]: I0811 03:44:42.482590 21221 kuberuntime_manager.go:767] Back-off 2m40s restarting failed container=kube-apiserver pod=kube-apiserver-kube-master_kube-system(7a1b9f5f...99abbbbd1143041)
Aug 11 03:44:42 kube-master kubelet[21221]: E0811 03:44:42.482657 21221 pod_workers.go:186] Error syncing pod 7a1b9f5fe804e9cdf99abbbbd1143041 ("kube-apiserver-kube-master_kube-system(7a1b9f5fe804e9cdf99abbbbd1143041)"), skip...
Aug 11 03:44:43 kube-master kubelet[21221]: E0811 03:44:43.275748 21221 eviction_manager.go:243] eviction manager: failed to get get summary stats: failed to get node info: node "kube-master" not found
Aug 11 03:44:43 kube-master kubelet[21221]: W0811 03:44:43.523623 21221 cni.go:172] Unable to update cni config: No networks found in /etc/cni/net.d
Aug 11 03:44:43 kube-master kubelet[21221]: E0811 03:44:43.524070 21221 kubelet.go:2110] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is n...ig uninitialized
Hint: Some lines were ellipsized, use -l to show in full.
なぜか、動いている。 と言うことは、workerのほうの設定が間違ったのかもしれない…。
ネットワークの設定を修正
いろいろ、設定を見直していたら、masterとworkerがネットワーク的に繋がっていない、というまさかの事実が判明しました。 なので、AWS EC2のセキュリティポリシーを修正。 ただ、kubeadm initの段階では、これが問題の根源とは思えないものの、とりあえずworkerのkubeletを再起動。
[root@kube-node1 kubelet.service.d]# systemctl daemon-reload
[root@kube-node1 kubelet.service.d]# systemctl enable kubelet && systemctl restart kubelet
[root@kube-node1 kubelet.service.d]# systemctl status kubelet
● kubelet.service - kubelet: The Kubernetes Node Agent
Loaded: loaded (/etc/systemd/system/kubelet.service; enabled; vendor preset: disabled)
Drop-In: /etc/systemd/system/kubelet.service.d
└─10-kubeadm.conf, 90-local-extras.conf
Active: active (running) since Sat 2018-08-11 09:52:08 UTC; 40s ago
Docs: https://kubernetes.io/docs/
Main PID: 1512 (kubelet)
CGroup: /system.slice/kubelet.service
└─1512 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --cgroup-driver=systemd --cni-bin-dir=/opt/cni/bin...
Aug 11 09:52:29 kube-node1 kubelet[1512]: E0811 09:52:29.532070 1512 summary.go:102] Failed to get system container stats for "/system.slice/docker.service": failed to get cgroup stats for "/system.slice/dock.../docker.service"
Aug 11 09:52:29 kube-node1 kubelet[1512]: E0811 09:52:29.532552 1512 summary.go:102] Failed to get system container stats for "/system.slice/kubelet.service": failed to get cgroup stats for "/system.slice/kubelet.service": f...
Aug 11 09:52:34 kube-node1 kubelet[1512]: W0811 09:52:34.502572 1512 cni.go:172] Unable to update cni config: No networks found in /etc/cni/net.d
Aug 11 09:52:34 kube-node1 kubelet[1512]: E0811 09:52:34.502683 1512 kubelet.go:2110] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not...ig uninitialized
Aug 11 09:52:39 kube-node1 kubelet[1512]: W0811 09:52:39.503681 1512 cni.go:172] Unable to update cni config: No networks found in /etc/cni/net.d
Aug 11 09:52:39 kube-node1 kubelet[1512]: E0811 09:52:39.503775 1512 kubelet.go:2110] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not...ig uninitialized
Aug 11 09:52:39 kube-node1 kubelet[1512]: E0811 09:52:39.542387 1512 summary.go:102] Failed to get system container stats for "/system.slice/kubelet.service": failed to get cgroup stats for "/system.slice/kubelet.service": f...
Aug 11 09:52:39 kube-node1 kubelet[1512]: E0811 09:52:39.542404 1512 summary.go:102] Failed to get system container stats for "/system.slice/docker.service": failed to get cgroup stats for "/system.slice/dock.../docker.service"
Aug 11 09:52:44 kube-node1 kubelet[1512]: W0811 09:52:44.504722 1512 cni.go:172] Unable to update cni config: No networks found in /etc/cni/net.d
Aug 11 09:52:44 kube-node1 kubelet[1512]: E0811 09:52:44.504831 1512 kubelet.go:2110] Container runtime network not ready: NetworkReady=false reason:NetworkPluginNotReady message:docker: network plugin is not...ig uninitialized
Hint: Some lines were ellipsized, use -l to show in full.
なんとこれで、workerはactiveに。なぜ…。 ただ、failedって文字が見える。何でしょうか。
こちらに「cgroupが正しく指定されていないのかもしれないよ。」とのコメントが。
ここに記載されているように、vi /etc/sysconfig/kubeletにDAEMON_ARGS="--runtime-cgroups=/systemd/system.slice --kubelet-cgroups=/systemd/system.slice"と記載するも、再起動後に同じメッセージが出ています…。
さらに、masterのほうでkubeletを再起動したところ、今まで動いていたmasterのkubeletが、今度は起動せず。 謎が謎を呼ぶ展開で、手詰まり感が出てきました。
cgroup
[root@kube-master centos]# systemctl status kubelet
● kubelet.service - kubelet: The Kubernetes Node Agent
Loaded: loaded (/etc/systemd/system/kubelet.service; enabled; vendor preset: disabled)
Drop-In: /etc/systemd/system/kubelet.service.d
└─10-kubeadm.conf, 90-local-extras.conf
Active: activating (auto-restart) (Result: exit-code) since Sat 2018-08-11 09:53:25 UTC; 2s ago
Docs: https://kubernetes.io/docs/
Process: 32352 ExecStart=/usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS (code=exited, status=255)
Main PID: 32352 (code=exited, status=255)
Aug 11 09:53:25 kube-master systemd[1]: kubelet.service: main process exited, code=exited, status=255/n/a
Aug 11 09:53:25 kube-master systemd[1]: Unit kubelet.service entered failed state.
Aug 11 09:53:25 kube-master systemd[1]: kubelet.service failed.
/usr/bin/kubeletの実行に失敗したよ、と言われているが、どのように失敗したのかこれでは分からないので、実際に/usr/bin/kubeletを叩いてみました。
[root@kube-master centos]# /usr/bin/kubelet $KUBELET_KUBECONFIG_ARGS $KUBELET_CONFIG_ARGS $KUBELET_KUBEADM_ARGS $KUBELET_EXTRA_ARGS
I0811 09:54:10.452426 32398 server.go:408] Version: v1.11.2
I0811 09:54:10.452653 32398 plugins.go:97] No cloud provider specified.
W0811 09:54:10.452686 32398 server.go:549] standalone mode, no API client
W0811 09:54:10.481604 32398 server.go:465] No api server defined - no events will be sent to API server.
I0811 09:54:10.481645 32398 server.go:648] --cgroups-per-qos enabled, but --cgroup-root was not specified. defaulting to /
I0811 09:54:10.481907 32398 container_manager_linux.go:243] container manager verified user specified cgroup-root exists: []
I0811 09:54:10.481921 32398 container_manager_linux.go:248] Creating Container Manager object based on Node Config: {RuntimeCgroupsName: SystemCgroupsName: KubeletCgroupsName: ContainerRuntime:docker CgroupsPerQOS:true CgroupRoot:/ CgroupDriver:cgroupfs KubeletRootDir:/var/lib/kubelet ProtectKernelDefaults:false NodeAllocatableConfig:{KubeReservedCgroupName: SystemReservedCgroupName: EnforceNodeAllocatable:map[pods:{}] KubeReserved:map[] SystemReserved:map[] HardEvictionThresholds:[{Signal:memory.available Operator:LessThan Value:{Quantity:100Mi Percentage:0} GracePeriod:0s MinReclaim:<nil>} {Signal:nodefs.available Operator:LessThan Value:{Quantity:<nil> Percentage:0.1} GracePeriod:0s MinReclaim:<nil>} {Signal:nodefs.inodesFree Operator:LessThan Value:{Quantity:<nil> Percentage:0.05} GracePeriod:0s MinReclaim:<nil>} {Signal:imagefs.available Operator:LessThan Value:{Quantity:<nil> Percentage:0.15} GracePeriod:0s MinReclaim:<nil>}]} QOSReserved:map[] ExperimentalCPUManagerPolicy:none ExperimentalCPUManagerReconcilePeriod:10s ExperimentalPodPidsLimit:-1 EnforceCPULimits:true}
I0811 09:54:10.482016 32398 container_manager_linux.go:267] Creating device plugin manager: true
I0811 09:54:10.482130 32398 state_mem.go:36] [cpumanager] initializing new in-memory state store
I0811 09:54:10.482244 32398 state_file.go:82] [cpumanager] state file: created new state file "/var/lib/kubelet/cpu_manager_state"
I0811 09:54:10.486041 32398 client.go:75] Connecting to docker on unix:///var/run/docker.sock
I0811 09:54:10.486056 32398 client.go:104] Start docker client with request timeout=2m0s
W0811 09:54:10.487225 32398 docker_service.go:545] Hairpin mode set to "promiscuous-bridge" but kubenet is not enabled, falling back to "hairpin-veth"
I0811 09:54:10.487245 32398 docker_service.go:238] Hairpin mode set to "hairpin-veth"
W0811 09:54:10.487314 32398 cni.go:172] Unable to update cni config: No networks found in /etc/cni/net.d
W0811 09:54:10.489511 32398 hostport_manager.go:68] The binary conntrack is not installed, this can cause failures in network connection cleanup.
I0811 09:54:10.491076 32398 docker_service.go:253] Docker cri networking managed by kubernetes.io/no-op
I0811 09:54:10.497856 32398 docker_service.go:258] Docker Info: &{ID:G5LR:MEMI:KVCS:EIL3:K43A:33AY:QVW5:XPJX:LU4F:HQEC:KLEU:2WXL Containers:0 ContainersRunning:0 ContainersPaused:0 ContainersStopped:0 Images:7 Driver:overlay2 DriverStatus:[[Backing Filesystem xfs] [Supports d_type true] [Native Overlay Diff true]] SystemStatus:[] Plugins:{Volume:[local] Network:[bridge host macvlan null overlay] Authorization:[] Log:[]} MemoryLimit:true SwapLimit:true KernelMemory:true CPUCfsPeriod:true CPUCfsQuota:true CPUShares:true CPUSet:true IPv4Forwarding:true BridgeNfIptables:true BridgeNfIP6tables:true Debug:false NFd:16 OomKillDisable:true NGoroutines:23 SystemTime:2018-08-11T09:54:10.492950366Z LoggingDriver:journald CgroupDriver:systemd NEventsListener:0 KernelVersion:3.10.0-862.3.2.el7.x86_64 OperatingSystem:CentOS Linux 7 (Core) OSType:linux Architecture:x86_64 IndexServerAddress:https://index.docker.io/v1/ RegistryConfig:0xc4205a56c0 NCPU:2 MemTotal:3972677632 GenericResources:[] DockerRootDir:/var/lib/docker HTTPProxy: HTTPSProxy: NoProxy: Name:kube-master Labels:[] ExperimentalBuild:false ServerVersion:1.13.1 ClusterStore: ClusterAdvertise: Runtimes:map[docker-runc:{Path:/usr/libexec/docker/docker-runc-current Args:[]} runc:{Path:docker-runc Args:[]}] DefaultRuntime:docker-runc Swarm:{NodeID: NodeAddr: LocalNodeState:inactive ControlAvailable:false Error: RemoteManagers:[] Nodes:0 Managers:0 Cluster:0xc420403b80} LiveRestoreEnabled:false Isolation: InitBinary:/usr/libexec/docker/docker-init-current ContainerdCommit:{ID: Expected:aa8187dbd3b7ad67d8e5e3a15115d3eef43a7ed1} RuncCommit:{ID:5eda6f6fd0c2884c2c8e78a6e7119e8d0ecedb77 Expected:9df8b306d01f59d3a8029be411de015b7304dd8f} InitCommit:{ID:fec3683b971d9c3ef73f284f176672c44b448662 Expected:949e6facb77383876aeff8a6944dde66b3089574} SecurityOptions:[name=seccomp,profile=/etc/docker/seccomp.json name=selinux]}
F0811 09:54:10.497944 32398 server.go:262] failed to run Kubelet: failed to create kubelet: misconfiguration: kubelet cgroup driver: "cgroupfs" is different from docker cgroup driver: "systemd"
一番最後に、「kubeletのcgroupドライバーの設定がミスっててkubeletが作れないよ。dockerのcgroupドライバのsystemdとは違うものが設定されているよ。」と言われています。
また、cgroupという単語が出てきました。何か、ここが諸悪の根源なようです。 ただ、自分に取って暗号文としか思えないメッセージが出てきたので、調査です。
まず、cgroupを調べてみると、cgroupとは、プロセスをグループ化して，そのグループ内に存在するプロセスに対して共通の管理を行うために使われるものだそうです。 コンテナが、「プロセスの仮想化」と言う風に理解していたのですが、それを実現する具体的な仕組みがcgroupなのですね。
そして次に、cgroupfs。
cgroupがプロセスを操作する時に用いるファイル仮想的なシステムだそうです。
通常は、/procの下でカーネルのパラメータの確認などを行いますが、コンテナでは、cgroupfsを使うことで/procと同じ感覚でカーネルのパラメータを操作できる模様です。
そして最後に、cgroup driver。 これは、cgroupを操作するための仕組みのことで、先ほどのcgroupfsもその一つに当たります。 ただ、どのサイトを見ても、CentOS7では、cgroupfsではなくて、systemdに設定すると良いよ、と書かれています。
systemdとは、CentOSが標準的に用意している、あのシステム管理のsystemdのことでしょうか。 systemdの仕組みを利用して、コンテナ管理をする事ができるようです。
IBM knowledge centerにも、これが原因で立ち上がらないことがある、と解説しているページがありました。
https://www.ibm.com/support/knowledgecenter/ja/SSBS6K_2.1.0.3/troubleshoot/kubelet_fails.html
しかし、最初の手順書でも、そこはsystemdに統一するように設定を書いているはず…。 もうこれは、どこかのタイミングで、kubeletの起動をする際の設定ファイルの反映にミスっているのかもしれない。
よし、最初からやりなおそう
ということで、kubelet, kubeadmをアンインストールし、設定ファイルを削除して、もう一度、最初からやり直しました。
yum remove kubelet kubeadm -y rm -fr /etc/systemd/system/kubelet.service.d yum install kubelet kubeadm -y mkdir /etc/systemd/system/kubelet.service.d cat <<EOF > /etc/systemd/system/kubelet.service.d/90-local-extras.conf Environment="KUBELET_EXTRA_ARGS=--fail-swap-on=false" Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=systemd" EOF cat <<EOF > /etc/systemd/system/kubelet.service.d/10-kubeadm.conf Environment="KUBELET_CGROUP_ARGS=--cgroup-driver=systemd" EOF systemctl daemon-reload systemctl stop kubelet kubeadm init \ --pod-network-cidr=10.244.0.0/16 \ --apiserver-advertise-address=172.31.14.137
行けました…。なぜ…！？
確認作業。
root:~ $ kubectl get nodes NAME STATUS ROLES AGE VERSION kube-master NotReady master 13m v1.11.2 root:~ $ kubectl get pods --all-namespaces -o wide NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE kube-system coredns-78fcdf6894-k99lt 1/1 Running 0 15m 10.244.0.2 kube-master <none> kube-system coredns-78fcdf6894-t4fdw 1/1 Running 0 15m 10.244.0.3 kube-master <none> kube-system etcd-kube-master 1/1 Running 0 23s 172.31.14.137 kube-master <none> kube-system kube-apiserver-kube-master 1/1 Running 0 23s 172.31.14.137 kube-master <none> kube-system kube-controller-manager-kube-master 1/1 Running 0 22s 172.31.14.137 kube-master <none> kube-system kube-flannel-ds-llqwz 1/1 Running 0 41s 172.31.14.137 kube-master <none> kube-system kube-proxy-656k8 1/1 Running 0 15m 172.31.14.137 kube-master <none> kube-system kube-scheduler-kube-master 1/1 Running 0 22s 172.31.14.137 kube-master <none>
クラスタ参加でもトラブル
ここまできたら、あとは、workerをクラスタに参加させるだけです。
kubeadm init後に出力された「workerでこれを入力してね」と書かれたコマンドを入力します。
[preflight] Some fatal errors occurred:
[ERROR DirAvailable--etc-kubernetes-manifests]: /etc/kubernetes/manifests is not empty
[ERROR FileAvailable--etc-kubernetes-pki-ca.crt]: /etc/kubernetes/pki/ca.crt already exists
[ERROR FileAvailable--etc-kubernetes-kubelet.conf]: /etc/kubernetes/kubelet.conf already exists
[ERROR Port-10250]: Port 10250 is in use
[preflight] If you know what you are doing, you can make a check non-fatal with `--ignore-preflight-errors=...`
こちらのコメントが救いになりました。
workerでresetをかけてから、もう一度joinをしてみます。
kubeadm reset kubeadm join 172.31.14.137:6443 --token y2f5f8.zq847d48c3slbdgb --discovery-token-ca-cert-hash sha256:e4ae0e208659079b419ff727b9493bcbb973eea9d4bf89bb263360ab74f2be54
いけました。 試しに、masterでノードが追加されているかを確認します。
centos:~ $ kubectl get nodes NAME STATUS ROLES AGE VERSION kube-master Ready master 21m v1.11.2 kube-node1 Ready <none> 3m v1.11.2
ROLESが<none>になっているのが気になりますが、行けてそうです。
