인프런 커뮤니티 질문&답변
작성한 질문수
마스터 노드 쉘 스크립트 실행 시 오류
작성
·
2.8K
0
마스터 노드 쉘 스크립트 실행 시 다음과 같은 오류가 발생합니다.
-----
[root@m-k8s 1.6]# ./WO_master_node.sh
I1013 17:13:43.888031 3880 version.go:251] remote version is much newer: v1.22.2; falling back to: stable-1.20
[init] Using Kubernetes version: v1.20.11
[preflight] Running pre-flight checks
[WARNING IsDockerSystemdCheck]: detected "cgroupfs" as the Docker cgroup driver. The recommended driver is "systemd". Please follow the guide at https://kubernetes.io/docs/setup/cri/
[preflight] Pulling images required for setting up a Kubernetes cluster
[preflight] This might take a minute or two, depending on the speed of your internet connection
[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'
[certs] Using certificateDir folder "/etc/kubernetes/pki"
[certs] Generating "ca" certificate and key
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local m-k8s] and IPs [10.96.0.1 192.168.1.10]
[certs] Generating "apiserver-kubelet-client" certificate and key
[certs] Generating "front-proxy-ca" certificate and key
[certs] Generating "front-proxy-client" certificate and key
[certs] Generating "etcd/ca" certificate and key
[certs] Generating "etcd/server" certificate and key
[certs] etcd/server serving cert is signed for DNS names [localhost m-k8s] and IPs [192.168.1.10 127.0.0.1 ::1]
[certs] Generating "etcd/peer" certificate and key
[certs] etcd/peer serving cert is signed for DNS names [localhost m-k8s] and IPs [192.168.1.10 127.0.0.1 ::1]
[certs] Generating "etcd/healthcheck-client" certificate and key
[certs] Generating "apiserver-etcd-client" certificate and key
[certs] Generating "sa" key and public key
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "kubelet.conf" kubeconfig file
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[kubeconfig] Writing "scheduler.conf" kubeconfig file
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Starting the kubelet
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
[control-plane] Creating static Pod manifest for "kube-apiserver"
[control-plane] Creating static Pod manifest for "kube-controller-manager"
[control-plane] Creating static Pod manifest for "kube-scheduler"
[etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
[kubelet-check] Initial timeout of 40s passed.
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)
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.
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'
error execution phase wait-control-plane: couldn't initialize a Kubernetes cluster
To see the stack trace of this error execute with --v=5 or higher
The connection to the server 192.168.1.10:6443 was refused - did you specify the right host or port?
-----
다음은 한 번 더 실행했을 때 오류입니다
-----
[root@m-k8s 1.6]# ./WO_master_node.sh
I1013 17:36:26.417655 5928 version.go:251] remote version is much newer: v1.22.2; falling back to: stable-1.20
[init] Using Kubernetes version: v1.20.11
[preflight] Running pre-flight checks
[WARNING IsDockerSystemdCheck]: detected "cgroupfs" as the Docker cgroup driver. The recommended driver is "systemd". Please follow the guide at https://kubernetes.io/docs/setup/cri/
error execution phase preflight: [preflight] Some fatal errors occurred:
[ERROR Port-6443]: Port 6443 is in use
[ERROR Port-10259]: Port 10259 is in use
[ERROR Port-10257]: Port 10257 is in use
[ERROR FileAvailable--etc-kubernetes-manifests-kube-apiserver.yaml]: /etc/kubernetes/manifests/kube-apiserver.yaml already exists
[ERROR FileAvailable--etc-kubernetes-manifests-kube-controller-manager.yaml]: /etc/kubernetes/manifests/kube-controller-manager.yaml already exists
[ERROR FileAvailable--etc-kubernetes-manifests-kube-scheduler.yaml]: /etc/kubernetes/manifests/kube-scheduler.yaml already exists
[ERROR FileAvailable--etc-kubernetes-manifests-etcd.yaml]: /etc/kubernetes/manifests/etcd.yaml already exists
[ERROR Port-10250]: Port 10250 is in use
[ERROR Port-2379]: Port 2379 is in use
[ERROR Port-2380]: Port 2380 is in use
[ERROR DirAvailable--var-lib-etcd]: /var/lib/etcd is not empty
[preflight] If you know what you are doing, you can make a check non-fatal with `--ignore-preflight-errors=...`
To see the stack trace of this error execute with --v=5 or higher
cp: overwrite ‘/root/.kube/config’? configmap/calico-config created
customresourcedefinition.apiextensions.k8s.io/bgpconfigurations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/bgppeers.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/blockaffinities.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/clusterinformations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/felixconfigurations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/globalnetworkpolicies.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/globalnetworksets.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/hostendpoints.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ipamblocks.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ipamconfigs.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ipamhandles.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/ippools.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/kubecontrollersconfigurations.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/networkpolicies.crd.projectcalico.org created
customresourcedefinition.apiextensions.k8s.io/networksets.crd.projectcalico.org created
clusterrole.rbac.authorization.k8s.io/calico-kube-controllers created
clusterrolebinding.rbac.authorization.k8s.io/calico-kube-controllers created
clusterrole.rbac.authorization.k8s.io/calico-node created
clusterrolebinding.rbac.authorization.k8s.io/calico-node created
daemonset.apps/calico-node created
serviceaccount/calico-node created
deployment.apps/calico-kube-controllers created
serviceaccount/calico-kube-controllers created
poddisruptionbudget.policy/calico-kube-controllers created
-----
도와주세요ㅜ
답변 5
1
이렇게만 설명 드려서 문제 전체를 완전히 해결해주시는 건 불가능하다는 걸 저도 알고 있기에
에러 로그만 보고 대충 어느 부분에서 문제가 있는 것 같다는 일부분의 힌트 정도라도 얻고 싶었습니다
성의 없는 질문에 불쾌하셨다면 죄송합니다!
강사님의 기분을 상하게 하려는 마음은 하나도 없었는데
제 이미지를 스스로 실추시키고
강사님도 당황하실 만한 상황을 만들어서 너무 속상하네요..
사실 제가 정해진 데드라인 안에 졸업 작품을 마무리해야 하는 급박한 상황인데
vagrant up 하나 때문에 진도가 막혀서, 다음 작업을 진행 못해
팀원들에게 피해를 끼치게 될 것 같은
이런 상황이 스스로 너무 답답하고 한계를 느꼈고 (사실은 너무 스트레스를 받은 상태였습니다)
그래서 강사님께 에러 내용을 그대로 올려 드리고, 빨리 해결하고 싶은 마음에 그랬습니다.
하지만 그것은 제 사정일 뿐인 것이고, 강사님의 입장은 별도로 고려해야 하는 것이 옳은 일인데
전후사정 자초지종 설명 없이 질문만 떡하니 올려놓으니, 오해가 커질 법한 상황이었던 것 같습니다.
아무리 바쁘더라도 질문을 할 때는 예의를 갖추는 게 더 중요한 일인데, 제가 그런 부분을 등한시 했습니다.
이번 일은 반성하고, 앞으로는 조심하도록 하겠습니다. 죄송합니다!
? 강사가 좀 재밌는게 돈내고 배우는사람이 모를수도있지 글한단어에 빈정이상하셧나 ㅋㅋ 돈내고배우는사람이 깍듯이 사과하는데 한마디언급도없고 저밑에가보면 시키느대로 하는데도 안된다는데 의심이나하고.. '생각해보세요' '관리좀 해보세요' ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
상사야? ㅋㅋㅋㅋㅋㅋㅋ
1
안녕하세요
질문 주실때 육하원칙까지는 필요하지 않은데, 어딜 봐야 하는지는 말씀해 주시면 저에게도 좋고 질문자 분도 의도를 정확히 알릴 수 있을 수 있어서 좋을꺼 같습니다.
여러 번 위 아래로 오고가며 봤는데요
[ERROR Port-6443]: Port 6443 is in use
[ERROR Port-10259]: Port 10259 is in use
[ERROR Port-10257]: Port 10257 is in use
이거 같은데요. 영상을 다시 보시면 아무 것도 없는 상태입니다.
즉 다른 쿠버네티스 클러스터가 현재 켜져 있지 않은 상태입니다. 사용 중인 쿠버네티스 클러스터를 끄고 하시면 될 것 같습니다.
설명을 다시 들어보시고 Port에 대해서 찾아보셔서 Port에 대한 이해를 하시는게 필요하실 것 같습니다.
0
오... 드디어 해결됐습니다ㅜ
마스터 노드의 6443번 포트에 대한 방화벽을 열어주니 (sudo ufw allow 6443)
워커노드 2번과 3번도 정상적으로 join이 됩니다.
워커노드 1번은 방화벽을 열어주지도 않았는데도 join이 되고
2, 3번은 방화벽을 열어줘야 join이 된다는 게
일관성이 맞지 않아서 뭔가 이상하고 희한하네요 ㅎ;;
어쨌든 되긴 되네요..
이제는 실습도 정상적으로 진행되는지 확인해보겠습니다.
이미지를 제꺼를 안 쓰시려나요..제껀 방화벽 다 껐는데요.
그리고 현재 랩에서 사용하는 이미지(CentOS7)는 ufw 설치도 안되어 있는데요. 그건 우분투에 기본으로 설치되어 있을텐데요?
도움 주셔서 감사 드립니다 :) 남은 강의도 열심히 듣겠습니다! 쉽게 설명해주셔서 러닝커브를 줄여주심에 대단히 감사 드립니다 !!
추가) 방금 soft lockup / CPU stuck 관련 에러가 발생해서 1번 워커 노드가 맛이 가서, 다시 처음부터 4개 노드를 up 했는데, 1번 워커 노드를 up 하던 도중 TLS Bootstrap Timeout 에러가 발생했네요.. 방화벽 문제가 아닌 것 같기도 하네요..
(답변 안 해주셔도 됩니다.. 강사님 시간 뺏고 싶지 않습니다.. 알아서 잘 해보겠습니다ㅜ 좀 더 해보고 안 되면 포기하고 강의만 듣는 게 나을 것 같습니다.)
추가2) vagrant destroy -f w1-k8s-1.22 및 vagrant up w1-k8s-1.22로 해결 되어 1번 워커 노드 생성도 잘 되네요!
노드 4개 한꺼번에 생성이 안 되고, 따로 따로 하니까 또 되네요.. 정말 원인을 알 수 없네요 ^^; 원인 찾기 포기..
lockup이 발생하신다고요?
가상머신 자체가 문제가 있는거 같은데...얘기를 계속 들어보면...랩탑에 cpu feature나 기타 등등에 문제 또는 호스트 머신을 좀 관리해보시는게 좋을꺼 같아요.
여튼 즐거운 쿠버하세요
0
오 기본 구조가 똑같다면 정말로 다시 해봤을 땐 될 수도 있겠네요!
희망이 생겼어요! 꼭 다시 해보겠습니다!
추가1)
지금 다시 해보고 있는데요,
교재 vagrant file은 4개 노드를 다 provisioning하는 데에 약 20분 이내가 걸렸는데
강의 vagrant file은 master 노드 1개만 해도 30분이 넘게 걸리네요
[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'
에서 30분 동안 멈춰있어서
그냥 ctrl+c로 강제 종료하고
다시 vagrant destory 및 vagrant up하는 중입니다.
추가2)
엇 방금 vagrant destory 및 vagrant up을 하니까
똑같은
[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'
가 불과 1분만에 통과되네요..
이게 완전 조건이 똑같은데
실행할 때마다 됐다 안 됐다 하네요;;
(윈도우 cmd 창에서 진행 중인 작업에서 마우스 클릭을 하면 작업이 멈춰버리기 때문에
엔터 등을 통해 활성화시켜야 재동작한다는 것도 알고 있기에
그 부분도 신경을 항상 써왔는데 말이에요 ㅎㅎ;)
provision 도중 네트워크가 불안정하면 멈춰버리거나 에러가 나는 걸까요..
추가3)
마스터 노드와 w1노드는 매끄럽게 잘 생성 됐고요
w2노드에서는
[preflight] Running pre-flight checks
여기서 5분이 걸리고 다행히 잘 넘어갔는데
[kubelet-start] Waiting for the kubelet to perform the TLS Bootstrap...
여기서 5분 멈추더니, 자동으로 강제 종료 됐습니다.
자세한 로그는 다음과 같습니다.
---
w2-k8s-1.22: [preflight] Running pre-flight checks
w2-k8s-1.22: [preflight] Reading configuration from the cluster...
w2-k8s-1.22: [preflight] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -o yaml'
w2-k8s-1.22: [kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
w2-k8s-1.22: [kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
w2-k8s-1.22: [kubelet-start] Starting the kubelet
w2-k8s-1.22: [kubelet-start] Waiting for the kubelet to perform the TLS Bootstrap...
w2-k8s-1.22: [kubelet-check] Initial timeout of 40s passed.
w2-k8s-1.22: error execution phase kubelet-start: error uploading crisocket: timed out waiting for the condition
w2-k8s-1.22: To see the stack trace of this error execute with --v=5 or higher
The SSH command responded with a non-zero exit status. Vagrant
assumes that this means the command failed. The output for this command
should be in the log above. Please read the output to determine what
went wrong.
---
일단 vagrant destroy w2-k8s-1.22 명령어를 통해
2번째 워커 노드만 삭제한 뒤 다시 vagrant up w2-k8s-1.22 를 해보겠습니다.
추가4)
vagrant up w2-k8s-1.22 를 다시 했더니 이번에는 또 완전 다른 오류가 났습니다.
[preflight] Running pre-flight checks
똑같이 pre-flight에서 5분 정도 멈춰있다가
error execution phase preflight: couldn't validate the identity of the API Server
라는 오류가 발생했습니다.
뒤죽박죽이네요 정말..
구체적인 로그 내용입니다.
---
w2-k8s-1.22: [preflight] Running pre-flight checks
w2-k8s-1.22: error execution phase preflight: couldn't validate the identity of the API Server: Get "https://192.168.1.10:6443/api/v1/namespaces/kube-public/configmaps/cluster-info?timeout=10s": dial tcp 192.168.1.10:6443: connect: no route to host
w2-k8s-1.22: To see the stack trace of this error execute with --v=5 or higher
The SSH command responded with a non-zero exit status. Vagrant
assumes that this means the command failed. The output for this command
should be in the log above. Please read the output to determine what
went wrong.
추가5)
vagrant up w2-k8s-1.22 를 다시 했더니 이번에는 똑같은 오류가 났습니다.
[preflight] Running pre-flight checks
똑같이 pre-flight에서 5분 정도 멈춰있다가
error execution phase preflight: couldn't validate the identity of the API Server
라는 완전히 똑같은 오류가 발생했습니다.
추가6)
이번에는 vagrant destroy를 하지 않고
vagrant provision w2-k8s-1.22 를 했더니 이번에는 아까 전에 발생했던 TLS 오류가 났습니다.
[kubelet-start] Waiting for the kubelet to perform the TLS Bootstrap...
추가7)
한 번 더 vagrant provision w2-k8s-1.22 를 했더니
[ERROR FileAvailable--etc-kubernetes-kubelet.conf]: /etc/kubernetes/kubelet.conf already exists
[ERROR Port-10250]: Port 10250 is in use
[ERROR FileAvailable--etc-kubernetes-pki-ca.crt]: /etc/kubernetes/pki/ca.crt already exists
와 같은 오류가 발생했습니다.
아마도 destroy를 하지 않고 provision을 해서 발생한 에러 같습니다.
---
w2-k8s-1.22: Running: C:/Users/LG/AppData/Local/Temp/vagrant-shell20211014-27004-srgcxt.sh
w2-k8s-1.22: [preflight] Running pre-flight checks
w2-k8s-1.22: error execution phase preflight: [preflight] Some fatal errors occurred:
w2-k8s-1.22: [ERROR FileAvailable--etc-kubernetes-kubelet.conf]: /etc/kubernetes/kubelet.conf already exists
w2-k8s-1.22: [ERROR Port-10250]: Port 10250 is in use
w2-k8s-1.22: [ERROR FileAvailable--etc-kubernetes-pki-ca.crt]: /etc/kubernetes/pki/ca.crt already exists
w2-k8s-1.22: [preflight] If you know what you are doing, you can make a check non-fatal with `--ignore-preflight-errors=...`
w2-k8s-1.22: To see the stack trace of this error execute with --v=5 or higher
The SSH command responded with a non-zero exit status. Vagrant
assumes that this means the command failed. The output for this command
should be in the log above. Please read the output to determine what
went wrong.
추가8)
이번에는 work_nodes.sh 파일의 kubeadm join 명령에 --ignore-preflight-errors all이라는 옵션을 추가한 뒤
vagrant destroy w2-k8s-1.22 및 vagrant up w2-k8s-1.22를 해봤는데
아까 발생했었던
error execution phase preflight: couldn't validate the identity of the API Server
라는 오류가 여전히 발생했습니다.
추가9)
이번에는 work_nodes.sh 파일에 'kubeadm join ~' 명령어보다 위에
'kubeadm config images pull' 명령어를 추가하였습니다.
이렇게 했더니 config image가 pull 되는 과정이 로그에 보여질 뿐, 여전히
error execution phase preflight: couldn't validate the identity of the API Server
라는 에러가 발생하였습니다.
추가10)
이번에는
https://stackoverflow.com/questions/61305498/kubernetes-couldnt-able-to-join-master-node-error-execution-phase-preflight
의 답변을 참고하여
마스터 노드에서 sudo ufw allow 6443 로 방화벽을 열어주었더니 지금까지 문제가 해결 되고
두번째 워커 노드 생성이 정상적으로 이루어졌습니다!
두번째는 알려드릴수 있는데 생각해 보시는게 좋을꺼 같고요 첫 번째 것도 고민해 보시는게 좋을꺼 같아요. (참고: 이미지 받아오는게 왜 느린지 모르겠군요)
0
제 컴퓨터에 존재하는 모든 가상 머신을
VirtualBox 프로그램의 GUI를 통해
혹은 vagrant destroy 명령을 통해 완전 제거하고
C://User/.vagrant.d/boxes 내부의 폴더를 다 제거하고
C://User/VirtualBox VMs 내부의 폴더를 다 제거하고
다시 vagrant up를 했는데 에러가 발생하여서 질문을 드렸었습니다ㅎㅎ
혹시 C://User/.VirtualBox 내부의 log 파일이 남아 있어서 거기서 충돌이 나는 걸까 싶기도 했습니다.
일단 현재는 학교 실습 수업 진도를 따라 잡아야 해서
인프런 강의의 가상 머신은 없앴고, 교재의 가상 머신을 정상적으로 사용 중에 있습니다.
나중에 다시 인프런 강의의 가상 머신 vagrant up을 다시 시도할 때쯤
문제가 생긴다면 다시 질문 드리도록 하겠습니다!ㅎㅎ
정성스러운 답변에 감사드립니다!
아..지금 또 다시 보니 (-_- 볼때 새로운 느낌이려나..)
2번 째 실행에서는 당연히 기존에 kubeadm이 돌았던게 있어서 위의 얘기가 맞고요.
1번 째 실행에서는
이와 같은 에러 메시지 내용들을 살펴보면서 현재 랩탑/데스크탑이 어떤 문제인지 확인을 해야 되요. Final 메시지는 4분 이상 (정확히는 4분 40초라고 써 있네요) 걸려서 난 일단 중단하겠어 이지만, 그렇게 오래걸리는 이유는 무엇인지 알아야 하거든요. 저 내용들을 살펴보시고 문제를 찾으시는게 좋을꺼 같아요 (반복적으로 똑같이 난다면요) 근데...책의 랩이 돌아가는데, 현재의 랩이 안 돌아갈리는 거의 없어요;;;; 기존 구조는 같거든요.
etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
[kubelet-check] Initial timeout of 40s passed.
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)
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.
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'
error execution phase wait-control-plane: couldn't initialize a Kubernetes cluster
To see the stack trace of this error execute with --v=5 or higher
아 제가 좀 다시 봤는데요.
호호혹시요? 기존에 가상머신 설치하고 몇차례 계속 이거 실행하신거 아닌가요?
아래의 메시지를 보니까요. 이미 배포가 되어 있는 상태처럼 보여서요.
저거 나중에 static pod할 때 설명이 나오는데요.
(https://github.com/sysnet4admin/_Lecture_k8s_learning.kit/tree/main/ch7/7.3)
간단하게만 얘기하면 현재 컨트롤플레인을 구성하는 주요 Pod들이 kubeadm으로 배포(내려받고 설치?)되는거거든요. 근데 이미 있다는거는 언젠가 kubeadm을 하셨거나..돌린적이 있다는거라서요. 아마 현재 가정이 맞을꺼에요. kubeadm reset과 관련된 명령이 있긴 한데...그냥 다시 가상머신 부터 만드는게 좋으실꺼 같기도 해요.
[ERROR FileAvailable--etc-kubernetes-manifests-kube-apiserver.yaml]: /etc/kubernetes/manifests/kube-apiserver.yaml already exists
[ERROR FileAvailable--etc-kubernetes-manifests-kube-controller-manager.yaml]: /etc/kubernetes/manifests/kube-controller-manager.yaml already exists
[ERROR FileAvailable--etc-kubernetes-manifests-kube-scheduler.yaml]: /etc/kubernetes/manifests/kube-scheduler.yaml already exists
PS. 이게 아무래도 online의 단점 인거 같아요. 사실 다 같이 즐겁게 배우는 쿠버네티스 학습자인데(저도저도요) 아무래도 게시물은 건조하고...그 인간의 따뜻함이 안 보이다보니..뭐랄까..서로 속상하는 일이 많은거 같아요. 언제 오프라인 세미나때 꼭 뵙고 인사하고 즐겁게 공부하고 그랬으면 좋겠습니다 :)