kubectl get nodes 후 w2 노드 안보임

안녕하세요, Leeseul Kim님.튜터 비모입니다. 전달해주신 내용처럼 워커노드 2번이 정상적으로 구성되지 않은것으로 보입니다.이러한 vagrant를 통한 배포 시점의 오류는 스크립트를 통해 자동으로 진행되기 때문에배포하실 때와 마찬가지로 아래 명령어를 이용해 가상머신을 제거 후 다시 배포를 시도해보시고증상이 동일하신지 확인을 부탁 드립니다.> vagrant destroy(https://www.vagrantup.com/docs/cli/destroy)VM 배포시의 문제는 수강생분들의 환경(네트워크 상태나 다른 프로그램의 영향 등)에 따라 여러가지 이유로 오류가 발생할 수 있으므로안타깝게도 하나하나 트러블슈팅하기에 어려운 부분이 있어 큰 도움을 드리지 못하는 점 양해 부탁드립니다.증상이 계속 재발하신다면 아래 강의를 참조하셔서 미리 구성된 이미지를 다운로드 받아 진행해 보시길 바랍니다.- 8.010.쿠버네티스 실습 랩(v1.20+)을 Vagrant가 아닌 이미지로 바로 구성 설치하는 법(사진)혹시 추가로 궁금하신 점이 있으면 남겨주세요감사합니다 :)

설치 장애 한번만 더 도움 부탁드립니다 ㅠㅠ

안녕하세요, 안상혁님.튜터 비모입니다.전달해주신 메세지의 내용처럼 현재 컴퓨터에서 사용하고있는 IP 대역과 예제 실습을 위한 IP 대역이 같아 발생하는 문제로 보입니다.Bridged Network Address: '192.168.1.0'Host-only Network 'Realtek RTL8822CE 802.11ac PCIe Adapter': '192.168.1.0'설치 관련 파일들을 하나하나 수동으로 변경하실수도 있으나, 그외에도 예제 진행간 혼선이나 어려움을 겪으실 수 있어가급적 공유기 등 다른 네트워크에 접근하여 변경하시는 방법을 권고드립니다. 변경이 불가하신 환경이라면 vagrant file이 있는 경로에서 아래 파일들을 모두 변경 후 진행해보시길 바랍니다. VagrantfileLine 28: cfg.vm.network "private_network", ip: "192.168.56.10"Line 50: cfg.vm.network "private_network", ip: "192.168.56.10#{i}" master_node.shLine 5: --pod-network-cidr=172.16.0.0/16 --apiserver-advertise-address=192.168.56.10Line 22: # kubectl apply -f https://$raw_git/svc/metallb-l2config.yaml ( 주석처리 - 배포 이후 Master node에서 별도로 명령어 실행) work_nodes.shLine 5: --discovery-token-unsafe-skip-ca-verification 192.168.56.10:6443 (사진)배포 이후 마스터노드에서 아래와 같이 진행합니다.raw_git="raw.githubusercontent.com/sysnet4admin/IaC/master/manifests"curl https://$raw_git/svc/metallb-l2config.yaml -o metallb-l2config.yamlvi metallb-l2config.yamlLine 12: 192.168.56.11-192.168.56.19 # IP 변경kubectl apply -f ./metallb-l2config.yaml 혹시 추가로 궁금하신 점이 있으면 남겨주세요.감사합니다.

7.7 실습문의

안녕하세요, dukim73님.튜터 비모입니다.해당 증상에 대해서는 좀더 상세한 내용 확인이 필요해 보입니다.혹시 증상이 발생하셨을때 아래 명령어에 대한 결과값을 전달해주실 수 있으실까요?kubectl logs pod-adapter web-pagekubectl logs pod-adapter adapterkubectl describe pod pod-adapterkubectl get nodes -o wide 혹시 추가로 궁금하신 점이 있으면 남겨주세요감사합니다 :)

파드에 접속하는 것은 무엇을 의미하는 것인가요?

안녕하세요, 안상혁님. 튜터 비모입니다. 파드 안에 단일 컨테이너만 존재하는 경우 알고계신 내용처럼 당연히 해당 컨테이너로 연결되나 문의주신 사항인 하나의 파드 안에 여러개의 컨테이너가 존재하는 경우, 아래 문서에서 설명하는 내용과 같이 --container 또는 -c 옵션을 통해 쉘로 접근할 컨테이너를 지정하여 접근하게 됩니다. - Opening a shell when a Pod has more than one container https://kubernetes.io/docs/tasks/debug/debug-application/get-shell-running-container/#opening-a-shell-when-a-pod-has-more-than-one-container kubectl exec -i -t my-pod --container main-app -- /bin/bash 혹시 추가로 궁금하신 점이 있으면 남겨주세요 감사합니다 :)

cgroupdriver/systemd 관련

안녕하세요, lhc7427님. 튜터 비모입니다. 문의주신 경고의 경우 Cgroup driver를 systemd로 사용할 것을 권장한다는 메세지로 교육 실습에는 별다른 영향이 없으며 vagrant up 진행 시 해당 메세지 발생 이후에도 정상적으로 kubernetes 환경 구성이 되어야 합니다. 해당 메세지 발생 상태에서 멈추신다면 다른 이유일 것으로 보이며, 혹시 계속 기다리신다면 어떤 에러가 발생하는지 확인을 부탁 드립니다. 초기 구성 시 cgroup driver 설정에 대한 내용이 필요하시다면 아래 문서 참조 부탁 드립니다. - Configuring the kubelet cgroup driver https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/#configuring-the-kubelet-cgroup-driver 이미 확인해주신 내용과 같이 v1.22 에서는 기본적으로 systemd를 사용하나, 현재 강의는 v1.20을 기반으로 만들어졌습니다. 추후에는 실습 버전 변경이 예정되어 있으니 아래 내용 참조 부탁드립니다. -[예정] 쿠버네티스 실습 버전 변경 https://www.inflearn.com/news/499395 - Configuring the kubelet cgroup driver https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/#configuring-the-kubelet-cgroup-driver Note: In v1.22, if the user is not setting the cgroupDriver field under KubeletConfiguration, kubeadm will default it to systemd vgrant를 통한 구성 도중에 이러한 오류가 발생하는 경우 도움을 드리기 어려운 부분이 있어 증상이 계속 재발하신다면 아래 강의를 참조하셔서 미리 구성된 이미지를 다운로드 받아 진행해 보시길 바랍니다. - 8.010.쿠버네티스 실습 랩(v1.20+)을 Vagrant가 아닌 이미지로 바로 구성 설치하는 법 혹시 추가로 궁금하신 점이 있으면 남겨주세요 감사합니다 :)

컨테이너 내 command 부분 질문

안녕하세요, 김영진님. 튜터 비모입니다. 문의주신 사항은 아래 문서에서 설명하는 내용과 같이, 컨테이너 동작 시 정의한 커맨드와 인자를 통해 환경 변수를 사용하거나 스크립트를 실행하는 등 다양한 방법으로 이용하실 수 있습니다. 강의에서는 셸(/bin/sh)을 통해 -c 옵션으로 명령어를 읽어 nslookup을 수행하고, 그 결과에 따라 restartPolicy를 연습하기 위한 용도로 설정되었습니다. - 컨테이너를 위한 커맨드와 인자 정의하기 https://kubernetes.io/ko/docs/tasks/inject-data-application/define-command-argument-container/ 파드를 생성할 때, 파드 안에서 동작하는 컨테이너를 위한 커맨드와 인자를 정의할 수 있다. 커맨드를 정의하기 위해서는, 파드 안에서 실행되는 컨테이너에 command 필드를 포함시킨다. 커맨드에 대한 인자를 정의하기 위해서는, 구성 파일에 args 필드를 포함시킨다. - 셸 안에서 커맨드 실행하기 command: ["/bin/sh"] args: ["-c", "while true; do echo hello; sleep 10;done"] 일부 경우들에서는 커맨드를 셸 안에서 실행해야할 필요가 있다. 예를 들어, 실행할 커맨드가 서로 연결되어 있는 여러 개의 커맨드들로 구성되어 있거나, 셸 스크립트일 수도 있다. 셸 안에서 커맨드를 실행하려고 한다면, 이런 방식으로 감싸주면 된다. - sh — Linux manual page https://man7.org/linux/man-pages/man1/sh.1p.html -c : Read commands from the command_string operand 혹시 추가로 궁금하신 점이 있으면 남겨주세요 감사합니다 :)

NodePort와 LoadBalancer 의 get 명령 수행시 보여지는 Port(s)에 대해 문의합니다.

안녕하세요, sj님. 튜터 비모입니다. 문의주신 LoadBalancer 서비스 사용시 자동으로 생성되는 NodePort는 아래 문서에서 설명하는 내용과 같이, 할당된 External IP는 고정된 목적지로 직접 라우팅되는 것이 아니기 때문에 NodePort를 거쳐 트래픽이 목적지로 도달하기까지 라우팅을 하기 위해 사용됩니다. - 서비스 퍼블리싱 (ServiceTypes) https://kubernetes.io/ko/docs/concepts/services-networking/service/#publishing-services-service-types LoadBalancer: 클라우드 공급자의 로드 밸런서를 사용하여 서비스를 외부에 노출시킨다. 외부 로드 밸런서가 라우팅되는 NodePort와 ClusterIP 서비스가 자동으로 생성된다. - 서비스 IP 주소 https://kubernetes.io/ko/docs/concepts/services-networking/service/#ips-and-vips 실제로 고정된 목적지로 라우팅되는 파드 IP 주소와 달리, 서비스 IP는 실제로 단일 호스트에서 응답하지 않는다. 대신에, kube-proxy는 iptables (리눅스의 패킷 처리 로직)를 필요에 따라 명백하게 리다이렉션되는 가상 IP 주소를 정의하기 위해 사용한다. 클라이언트가 VIP에 연결하면, 트래픽이 자동으로 적절한 엔드포인트로 전송된다. - 외부 IP https://kubernetes.io/ko/docs/concepts/services-networking/service/#%EC%99%B8%EB%B6%80-ip 하나 이상의 클러스터 노드로 라우팅되는 외부 IP가 있는 경우, 쿠버네티스 서비스는 이러한 externalIPs에 노출될 수 있다. 서비스 포트에서 외부 IP (목적지 IP)를 사용하여 클러스터로 들어오는 트래픽은 서비스 엔드포인트 중 하나로 라우팅된다. - 로드밸런서 NodePort 할당 비활성화 https://kubernetes.io/ko/docs/concepts/services-networking/service/#%EB%A1%9C%EB%93%9C%EB%B0%B8%EB%9F%B0%EC%84%9C-nodeport-%ED%95%A0%EB%8B%B9-%EB%B9%84%ED%99%9C%EC%84%B1%ED%99%94 type=LoadBalancer 서비스에 대한 노드 포트 할당을 선택적으로 비활성화할 수 있으며, 이는 spec.allocateLoadBalancerNodePorts 필드를 false로 설정하면 된다. 노드 포트를 사용하지 않고 트래픽을 파드로 직접 라우팅하는 로드 밸런서 구현에만 사용해야 한다. 공식 문서는 아니지만 LoadBalancer 트래픽이 pod로 도달하기까지의 보다 자세한 내용이 알고싶으시다면 아래 문서를 참조해주시길 부탁 드립니다. - Kubernetes: from load balancer to pod https://medium.com/google-cloud/kubernetes-from-load-balancer-to-pod-3f2399637b0c (사진) 혹시 추가로 궁금하신 점이 있으면 남겨주세요 감사합니다 :)

nginx pod는 워커노드 2에 있는데 1번, 3번 워커노드에서도 웹접속이 되는 이유가?

안녕하세요, sj님. 튜터 비모입니다. 테스트해보신 것 처럼 NodePort로 expose 시, 해당 Pod가 올라간 노드 외 다른 노드에서도 접속이 가능한 이유는 아래 공식문서에서 설명하고 있는 내용과 같이 모든 노드에서 동일한 포트를 서비스로 프록시하기 때문입니다. - NodePort 유형 https://kubernetes.io/ko/docs/concepts/services-networking/service/#type-nodeport 각 노드는 해당 포트 (모든 노드에서 동일한 포트 번호)를 서비스로 프록시한다 이해에 도움을 드리기 위해 ibm cloud 문서의 그림을 첨부드리오니 참조 부탁 드립니다. - NodePort https://www.ibm.com/cloud/architecture/content/course/ibm-cloud-private-networking/nodeport/ (사진) 혹시 추가로 궁금하신 점이 있으면 남겨주세요 감사합니다 :)

Scale 관련 질문 드립니다.

안녕하세요, 끼야호우님. 튜터 비모입니다. 이후 강의를 쭉 보시면서 따라하신다면 알게되시겠지만, 쿠버네티스 오브젝트에 대해 찾아보시면 좀더 이해에 도움이 되실 것 같습니다. 현재 학습중이신 디플로이먼트를 예로 들면 아래와 같이 오브젝트를 생성할 때, 의도한 상태를 기술한 오브젝트 spec을 가지고 있으며 컨트롤러는 이 spec을 읽고 의도한 상태에 가깝게 만드는 역할을 합니다. - 쿠버네티스 오브젝트 이해하기 https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/ --- 예를 들어, 쿠버네티스 디플로이먼트는 클러스터에서 동작하는 애플리케이션을 표현해줄 수 있는 오브젝트이다. 디플로이먼트를 생성할 때, 디플로이먼트 spec에 3개의 애플리케이션 레플리카가 동작되도록 설정할 수 있다. 쿠버네티스 시스템은 그 디플로이먼트 spec을 읽어 spec에 일치되도록 상태를 업데이트하여 3개의 의도한 애플리케이션 인스턴스를 구동시킨다. 만약, 그 인스턴스들 중 어느 하나가 어떤 문제로 인해 멈춘다면(상태 변화 발생), 쿠버네티스 시스템은 보정(이 경우에는 대체 인스턴스를 시작하여)을 통해 spec과 status간의 차이에 대응한다. --- 따라서 문의주신 사항에 답변은 아래와 같습니다. 1. scale을 통하여 pod를 늘렸을 때 사용자가 실수로 scale된 pod를 삭제하면 자동으로 설정된 scale 값을 유지하기 위해 다시 생성 되나요? - 디플로이먼트의 현재 상태(status)와 명세(spec) 간 차이가 발생하면 시스템에서 이를 복구하게 됩니다. 2. 다른 질문은 scale 을 통하여 복제된 pod는 최초 생성된 pod를 복제하는 부분인가요? 아니면 최초 생성된 pod의 이미지를 가지고 생성되는 것인가요? - 기존의 pod를 복제하는것이 아닌 명세(spec)에 작성된 내용을 기반으로 추가적인 새 pod를 생성합니다. 제 답변이 많이 부족하여 이해에 도움이 되실만한 문서를 전달드리오니 참조 부탁 드립니다. - 컨트롤러 https://kubernetes.io/ko/docs/concepts/architecture/controller/ - 디플로이먼트 사양 작성 https://kubernetes.io/ko/docs/concepts/_print/#%EB%94%94%ED%94%8C%EB%A1%9C%EC%9D%B4%EB%A8%BC%ED%8A%B8-%EC%82%AC%EC%96%91-%EC%9E%91%EC%84%B1 혹시 추가로 궁금하신 점이 있으면 남겨주세요 감사합니다 :)

vagrant up시 에러가 발생합니다.

안녕하세요, 얼티밋님. 튜터 비모입니다. 캡처해주신 내용과 같이 마스터 노드의 초기구성부터 문제가 있었던 것으로 보입니다. 금일(05/05)자로 코드를 다시 다운로드 받아 내부 환경에서 재실행을 해보았으나, 정상적으로 실행됨을 확인하였으며 이러한 vagrant를 통한 배포 시점의 오류는 스크립트를 통해 자동으로 진행되기 때문에 배포하실 때와 마찬가지로 아래 명령어를 이용해 가상머신을 제거 후 다시 배포를 시도해보시고 증상이 동일하신지 확인을 부탁 드립니다. > vagrant destroy (https://www.vagrantup.com/docs/cli/destroy) VM 배포시의 문제는 수강생분들의 환경(네트워크 상태나 다른 프로그램의 영향 등)에 따라 여러가지 이유로 오류가 발생할 수 있으므로 안타깝게도 하나하나 트러블슈팅하기에 어려운 부분이 있어 큰 도움을 드리지 못하는 점 양해 부탁드립니다. 혹시 추가로 궁금하신 점이 있으면 남겨주세요 감사합니다 :)