CRD내용중에

쿠버네티스 운영자 소희 DevOps 엔지니어는 쿠버네티스를 운영하는 사람입니다. 만들어져 있는 오픈소스나 운영에 알아야하는 쿠버네티스 리소스들을 사용하는 역할이고요. 쿠버네티스 개발자는 운영자가 사용할 수 있는 오픈 소스를 개발하는 사람이라고 이해하시면 되세요. 채용 공고를 보더라도 DevOps 엔지니어와 쿠버네티스 개발자를 별도로 모집하고 있고요. 강의에서 써본 Grafana나 Nginx 오픈소스들을 기업마다 커스터마이징을 해서 추가 개발 하거나 비슷한 용도의 App을 직접 만들기도 합니다. 그리고 이건 개발의 영역이고 쿠버네티스 개발자가 코딩을 하고 이미지 생성, 그리고 배포를 위한 리소스들을 만들어요. 이 리소스를 만들 때 실력이 있다면 CRD를 활용할 수 있고요.DevOps 엔지니어는 이렇게 만들어진 패키지를 배포하고 관리하는 역할이라고 보시면 됩니다.

worker node1 접속 후 토큰 붙여놓기 후

일단 master는 정상적으로 동작하고 있는 상태일까요?kubectl get pod -A 를 했을 때 모든 Pod들이 Running 인지 확인이 필요합니다. 그리고 master에서 아래 명령을 직접 실행해서 토큰을 발급 받고,kubeadm token create --print-join-command출력된 내용을 다시 한번 workernode에서 실행해 보시겠어요?

csi-node-driver 클러스터 노드 재부팅후 CrashLoopBackOff

안녕하세요.저도 ui에서 종료를 하거나. 급할때는 컴터 파워를 눌러서 강제 종료하기도 합니다 ㅎㅎ. 그래도 딱히 문제는 없어요 혹시 다시 기동할때도 매번 같은 문제가 뱔생하나요? 일시적인 문제일 수도 있고요. 자주 해당 문제가 발생한다면, 재설치를 한번 권해드리고요. 그래도 마찬가지라면 자원이나 성능 문제일 수도 있어요. 아래 링크 내용 한번 참고 해주시기 바랍니다.https://cafe.naver.com/kubeops/25?tc=shared_link

DaemonSet 내용중에

AI 인턴이 잘 설명해준 것 같네요. 각각의 노드에 설치된 Agent 들이 있고, 서버 역할을 하는 프로메테우스는 각각의 Agent에 접근해 데이터를 수집합니다. 그래서 이렇게 중앙 처리를 하는 컴포넌트를 서버 역할이라고 표현 드린 거예요. 그걸 서버역할이라고 말한건데 듣는 사람에 따라 다르게 생각할 수가 있겠습니다. 그리고 배포는 최종적으로 쿠버네티스엔 DaemonSet가 생성됩니다. 근데 이건 노드의 정보를 수집하는 Node Agent의 경우가 그렇고, kube-apiserver나 etcd 등 꼭 노드마다 Pod가 배포될 필요가 없을 경우에는 Deployment 형태로도 배포되고요. 배포는 Helm 패키지를 통해 배포가 되는데, 이곳을 보시면 명시적으로 DaemonSet yaml 파일은 없고, 강의를 들으셨으면 아시겠지만, Operator가 만들어줘요. 그리고 그 Operator는 아래 파일을 보고 만듭니다. https://github.com/k8s-1pro/install/blob/main/under-thesea/k8s-cluster-1.30/kube-prometheus-stack-0.78.1/helm-66.2.1/templates/prometheus/prometheus.yaml

Readiness probe warning

안녕하세요. 300번이면 성공이지만 경고(warning)를 남기는 게 맞긴 합니다. 간혹 Probe에 path를 잘못 넣으면 그런 에러가 나는데, 현재 강의에서 어떤 내용을 실습중이고, 생성한 Yaml 파일이 뭔지 알 수 있을까요?

강의내용설명중 이해안가는부분이 있습니다.

다시 강의를 들어보니, 틀린말은 아니긴 한데, volumeClaimTemplates가 두 번 들어가다보니, 듣는 사람 입장에서는 혼동이 생길 수 있는 것 같아요.다시 정리를 드리면 StatefulSet에서는 Pod 별로 PVC/PV를 만들게 되니 구성은 더 어렵지만, volumeClaimTemplates 덕분에 만들기는 쉬워졌다는 의미 입니다.영상에서 volumeClaimTemplates를 두 번 언급한 부분 중에 하나를 제거하는 게 낫겠네요.

강의내용설명중 이해안가는부분이 있습니다.

제가 봐도 이상한 말이네요; 아마 편집이 잘못됐거나, 혹은 말 실수가 있었던 것 같은데, 저도 강의를 다시 한번 들어보고 답변 드리겠습니다. 감사합니다.

tls ingress 기본값 설정

tls 적용된 ingress는 redirect 기본값이 true라고 적어주셨는데kubectl get ingress -n anotherclass-322 portal-3222 -o yaml 로 보면 안나오는데위에 기본값은 원래 있다는 의미로 저렇게 적어만 주셨던걸까요? -> 네, 맞습니다. 제가 자료실에 설명을 좀 모호하게 적어 놓은 거 같아 문구를 좀 수정했어요. 그리고 portal.com:31443/hostname으로 접속하면 페이지가 열리는데portal.com:31080/hostname 요청하면 https로 리다이렉션 되니 페이지가 열려야 하는거죠?그런데 노드포트가 아니니 안열리는것 뿐인거고...실제는 portal.com:31443/hostname이거 요청했을때와 똑같은 페이지가 열려야 하는거죠?-> 네, 그래서 강의에서 말씀드린 설정으로 [1-5-3. configuration-snippet 옵션 적용]이걸 해주시면 31443으로 연결이 되요.

tls인증서 관련시

다시 설명드리자면, 인증서에는 공인[일반(도메인이름)/와일드카드(*.com)]인증서와 사설인증서가 있고요. 이 인증서들은 Nginx App안에 설정할 수도 있고, Ingress를 통해서도 설정할 수 있습니다. (Ingress에만 설정할 수 있는 인증서라는 건 없다고 보시면 되요.)차이점은 Nginx에 인증서를 넣으면, 해당 nginx를 통하는 모든 트래픽에는 tls가 적용되고, Ingress에 인증서를 넣으면 해당 Ingress에 연결된 Service로 가는 트래픽에만 tls가 적용됩니다. 두 곳 모두 설정할 경우 Default는 nignx, 그리고 Ingress 사용시에는 Ingress의 인증서가 적용되고요. 마지막으로, 와일드 카드 인증서가 일반 인증서에 비해서는 비싸지만, 그레도 사내에 여러 도메인 사용이 필요하다면 훨씬 경제적이라고 볼 수 있습니다.

노트포트타입서비스 만들때 관한 설명

동시에 각각 들어간다는 말이 아니고 특정 워커노드로 들어가서 그 노드의 iptables로 들어가는거지요?-> 네 맞습니다. iptables와 kube-proxy역할이 각각 다른건가요? iptables는 로드밸런싱역할을 해주는 것인가요?-> 역할은 다르다고 볼 수 있어요. 실제 트래픽을 로드벨런싱하고, 트래픽을 전달하는 실질적인 주체는 iptable입니다. kube-proxy는 내가 쿠버네티스에 Service를 생성하거나 Pod에 연결됐을 때 만들어지는 IP 정보들을 iptable에 기록하는 역할인 거죠. 그럼 Pod에서 특정 IP로 트래픽을 보냈을 때 iptable에 추가된 규칙에 따라 전송이 되게 됩니다.