섹션5 21강 Loki 설치 진행중인데

안녕하세요.저도 아래 이미지와 같이 다시 설치해본 결과 문제가 없었습니다.혹시 설치 가이드와 다른 명령을 준 부분이 있었을까요?(사진) 아니면 remote 추가에서 본인의 github 계정으로 변경하셨을까요? 강의 자료 그대로 변경없이 하시면 되고, 만약 본인의 github로 fork를 하셨다면, 본인의 id/pw를 입력하시면 될 거예요.

섹션5 21강 Loki 설치 진행중인데

안녕하세요. 먼저 진행에 불편함을 드려 죄송합니다.월래는 로그인과정 없이 그냥 되야하는게 맞는데, 제 계정에 뭔가 토큰 문제가 있는지 저도 확인을 해봐야할 것 같습니다. 내일 오후중으로 확인 가능할 것 같고요. 일단 강의로만 보시고 조치가 완료되는 대로 다시 답변 드시겠습니다.

무게감있게 설치하는 방법 - Mac 환경 질문

안녕하세요.실습 영상은 영상 하단 [수업 노트 보기]를 보시면Mac일 경우 별도로 가이드 된 자료실이 있습니다.(사진) 이 자료를 찾으시는 건지? 아니면 이 자료 내용이 부족하여 더 추가적인 내용이 필요한 말씀인지요?

강의 잘보고있습니다. 책좀 추천받고싶습니다.

안녕하세요. 아래 링크가 답변이 될 거예요~!https://cafe.naver.com/kubeops/99

PVC실습 질문 (왜 hostPath 실습이 영향을 주는지)

안녕하세요. 아래, 오른쪽 그림처럼 앞에서 hostPath를 실습했을 때 worker1에는 /node-v 를 사용했었습니다.근데 PVC/PV 수업에서 PV에 경로를 /node-v로 지정했기 때문에 같은 path를 사용하게 되었고그래서 hostPath때 실습했던 파일이 PVC/PV에서도 보이게 되는 상황입니다. (사진)

내부 Pod간 통신 시 Nginx 사용

안녕하세요.첫 번째 단계는 말씀하신 것 처럼 Nginx를 사용하지 않고, Server를 통해 Pod간의 통신을 하는 겁니다.이게 가장 편하게 사용하는 형태가 맞고요. 근데 분명 한계도 존재해요.단순 호출만 생각하면 가장 간단한데, 실무에서는 트래픽을 관리해야 되는 상황들이 생기거든요.예를 들어 Server->Pod 구조에서는 Pod로 트래픽이 라운드 로빈으로 균등 분산 됩니다.근데 그러면 부하가 높은 Pod에도 똑같은 양의 트래픽이 들어가게 되요.하지만 Nginx에는 트래픽 분산을 관리해주는 기능이 있고요.그래서 Pod -> Nginx -> Pod 구조 쓰게 되면 Nginx에서 여러 Pod들의 부하 상태를 봐가면서 트래픽을 보내는 기능을 사용할 수 있게 됩니다.하지만 Nginx의 기능에도 한계가 있고요.더 섬세한 트래픽 관리를 생각하면 Istio를 적용하기도 합니다. 물론 사용방법은 Nginx보다 더 어렵지만 그에 상응하는 좋은 기능들을 제공해줘요.그래서 결론적으로 말씀드리면, 실무라고해서 처음부터 무거운 툴을 사용할 필요는 없긴 합니다. 내 운영 환경에 복잡도가 낮아서, 요구사항도 적다면 쿠버네티스 기본 기능만으로도 충분하고요.대규모 환경으로 갈 수록, 요구되는 기능들이 생길 수록 그에 적합한 툴을 써야되는 상황이 생기게 됩니다.그렇기 때문에 공부하는 입장에서는 닭 잡는 칼로 닭을 잡고, 소 잡는 칼을 써서는 소를 잡을 줄 아는 역량이 필요해요.일단은 잘 공부하고, 정리해 놓고요. 필요한 상황에 정리해 놓은 내용을 보고 빨리 대응할 수 있는 준비를 한다고 보시면 됩니다 :)

NFVO 플랫폼 관련

안녕하세요. 제가 개발한 건 HPE 사내 플랫폼이긴 하지만, NFVO 자체는 네트워크 기능 가상화 아키텍쳐로 인터넷 검색해보면 많이 나옵니다. 해당 아키텍쳐를 준수해서 인프라 관리 솔루션을 만들었다고 이해하시면 되세요.

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와는 별개의 역할을 하는 로직인지를 생각하는 게 먼저 입니다.추가 질문 있으시면 말씀해주세요.