ingress실습에서 canary-v2 를 지우고 canary-kr 을 생성해야하는 이유

네, 하나만 두고 써야 합니다. 일반적으로 기존 canary가 우선 적용되긴 하는데, 글쎄요.. 이건 nginx 버전에 따라 다를 거 같기도 하고, 확답을 드리기 힘들겠네요...ㅠ

로컬 개발환경 구축시 k8s 환경에 대한 테스트는 어떻게 하는지 궁금합니다.

정답은 없습니다. 개발자의 역량껏 이라고 할 수 있을 거 같아요.제 강의에서는 로컬을 위한 최소한의 개발 환경인 셈입니다. 당연히 본인이 쿠버네티스를 잘 하면 직접 로컬에 k8s 환경을 구축해 보는 게 제일 좋죠. 개발자가 관심 있어서 직접 해보는 건 대견한 느낌이지만, 관심이 없는 개발자 한테 그 정도까지 하라는 건 오히려 비효율적인 감이 있습니다. 공부해 보셔서 아시겠지만 쉽지 않기 때문에, 억지로 시키기엔 환경 구축에 매달리느라 개발을 못하게 되는 거죠. 아, 그리고 도커로 이미지를 띄우는 작업은 개인 로컬 환경입니다. 개발 환경이랑은 달라요. 개발 환경은 검증, 운영과 똑같은 환경일 뿐 여러 개발자들이 함께 쓰는 인프라 환경입니다. 로컬 환경은 혼자서 자신의 개발에 관련된 최소한의 App만 도커로 띄우는 환경이고요.

helm hook과 Pod initContainer 중 선택

Helm은 배포를 위한 작업입니다.Main App 입장에서 처음 배포시 사전에 먼저 기동되고 있어야 하는 App이 필요할 때는 pre-install을 씁니다.만약 Helm으로 배포되는 App이 (Server, DB) 이렇게 두 가지이고, 최초 배포시 DB부터 기동 된 후에 Server를 배포 하기 위해서는 pre-install을 쓰는 게 맞고요.initConatiner는 Main Container를 항시 보조하기 위한 기능이에요.DB를 먼저 배포 했다고 하더라도, Server 입장에서는 initContainer를 통해 DB가 통신 가능한 지를 한번 더 체크해서, ok되면 main Container를 기동 시킬 수 있어요. 그럼 main container에서는 항상 DB는 살아 있다는 조건에서 로직을 짜면 됩니다.결국 initContainer는 Main Container의 기능을 분산 시키기 위한 용도 인거죠. 그래서 Pod가 재기동 될때마다 같이 재시작 되면서 DB를 체크해주는 반복적인 동작을 하게 되고요.근데 DB를 뛰우기 위해, initContainer가 mainContainer보다 먼저 기동될 수 있다고해서 여기에 DB를 담지 않습니다.이 정도 설명이면 어떤 상황을 위해 initContainer와 pre-install를 구별해서 쓰는 건지 느낌이 오시나요?단지 둘 다 main container보다 먼저 실행을 시킬 수 있다는 이유만으로 고민을 해야 되는 요소는 아니예요. 내가 main container 보다 먼저 실행시켜야 하는 로직이, main container 를 보조하기 위한 목적인지, 아니면 main container와는 별개의 역할을 하는 로직인지를 생각하는 게 먼저 입니다.추가 질문 있으시면 말씀해주세요.

vm 실행 후 rocky linux 초기 세팅 화면이 안나옴

안녕하세요.일단 이상해 보이는 게 시스템 입니다.Mac의 경우 아래와 같이 QEMU 엔진에, ARM 시스템이 설정되 있어야 하는데, 이 부분이 다른 것 같아요. (사진)이미지는 이걸로 먼저 해주시면 되세요.: https://dl.rockylinux.org/vault/rocky/9.2/isos/aarch64/Rocky-9.2-aarch64-minimal.iso

Operator / CRD 을 강의에서 다루는지 궁금합니다.

AI인턴이 잘 알려 줬네요. 해당 개념은 오픈소스들을 사용할 때 많이 나오고, 그래서 본격적으로 오픈소스 단계인 Sprint4에서 나옵니다.

섹션8 강의자료 중 설명하지 않은 내용 질문

혼란을 드려 죄송합니다. 수정해서 다시 업로드 하였으니, 해당 장표는 무시해 주세요 🙂감사합니다.

replicaset을 delete할 때 cascade 영향을 받는 Pod들

안녕하세요. delete cascade 옵션 명령어를 수행했을 때 두 Pod모두 살아남는 게 맞고요. 제가 카페 어느부분에서 pod1만 살아남는다고 했는지 알려주실 수 있으실까요? 그랬다면 제가 잘못 표기를 한 거고 수정하겠습니다.

실무 관점에서

네, 당장 배포에 대한 부분이 필요한 게 아니라, 쿠버네티스 자체 리소스에 대한 이해가 더 급하다면, Sprint1에서 Sprint3로 가도 무방합니다.

K8s 대시보드의 신규 리소스 생성시 이슈

안녕하세요.해당 에러는 AI인턴에 제대로 설명해주네요.아마 현재 대시보드에 지정된 namespace와 현재 yaml 내용안에 있는 namespace와 다를 거예요.kubectl의 경우, 대시보드와는 별개로 yaml에 지정한 namespace로 생성이 됩니다.

데시보드에서 파드 생성 안됨

대시보드 상단에 네임스페이스를 Default로 변경해 보시겠어요?실수할 수 있는 부분이라 자료실에도 [Pod 생성시 확인 사항]으로 적어 놨는데, 참고해보시면 됩니다.https://cafe.naver.com/kubeops/497