Image Updater에서 새 Image가 감지되지 않아요

좋은 내용 공유 감사합니다!

강사님 한번에 질문을 하게 되면 좋은데 그렇지 못해 죄송합니다.

내용이 적지 않아 해당 부분을 다 설명 드리긴 힘들 것 같고요.아래 문서 참고 하시면서 공부해 보시길 권해 드릴께요.https://argo-rollouts.readthedocs.io/en/stable/getting-started/nginx/?utm_source=chatgpt.com

Project URL와 Repository URL의 차이가 궁금합니다.

안녕하세요. 대부분 그냥 지나치는 내용인데 잘 질문해 주셨네요. 처음 Github project에 Project url를 지정하는 건 빌드 할 때 특별한 기능은 없습니다. 안 넣어도 문제없어요. 저도 형식적으로 넣어주던 습관이 있어서 계속 넣어주긴 하고요.이렇게 하면 한 가지 기능이 있긴 한데, 아래 그림과 같이 해당 Job에 연동되는 Github 링크가 어디인지 연결해 줍니다. 그래서 잘 쓰면 나쁘지 않고, 안 써도 문제 없는 부분 이예요.(사진)

jenkins pipeline step 3 실습 진행 중 VM 다운 및 에러 발생에 관한 질문 드립니다.

고생 많이 하셨겠네요. 저도 그 문제로 몇 달 동안 고생 했던 적이 있어요.아래 링크와 같은 문제로 보이는 데 한번 확인해 보시겠어요?https://cafe.naver.com/kubeops/25

현업에서 startupProbe 사용에 대한 질문입니다.

앱이 컨테이너 시작 후 1~2초 안에 바로 포트 바인딩하고 응답 가능한 상태가 된다면, 바로 LivenessProbe가 호출되도 정상 응답을 할거고, 그럼 StartupProbe가 없어도 문제가 없습니다. 하지만 이 경우에도 확인해 볼 사항은 "정말 서비스가 온전한 상태 인가?" 입니다. 기동이 된 후에 트래픽이 쏟아져 들어온다 했을 때 문제가 없다는 것 까지 확인 되면 StartupProbe를 쓸 필요는 없죠. StartupProbe가 이걸 위한 목적이고, 그렇기 때문에 이런 사항을 넘어서 StartupProbe를 써야되는 경우는 없습니다.

마지막 해수편 강의 실습편 너무 어렵네요 ㅠㅠ

해수편 부터 다양한 오픈소스들이 들어오고, 각 오픈소스들은 저마다의 사상이나 설정들이 가지각색이기 때문에 어려운 게 맞습니다. 쿠버네티스가 이렇게 진입 장벽이 있는 분야라고 할 수 있고요. 그리고 그걸 처음부터 다 알고 시작할 수는 없습니다. 강의를 통해 전반적인 흐름을 파악하고, 실무에서 새로운 오픈소스를 사용하게 됐을 때, 그래도 20% 정도 아는 내용이 있으면 그걸로 시작하는 거라고 보시면 되요. 나머지 80%는 또 그때그때 최신 버전을 찾아가며, 기능을 이해하고 공부해야 합니다. 그리고 솔루션 마다 모든 이미지를 쿠버네티스를 위해서 만든 건 아닙니다. [컨테이너 이미지 = 쿠버네티스]라고 생각하기 쉬운데, 쿠버네티스를 안쓰고, 기존 환경 구성에서 VM이 아닌 그냥 컨테이너만 띄우는 경우도 많아요.

강사님 질문 드립니다.

인그레스에서의 Blue/Green 배포 방식은 Ingress 리소스에서 backend 서비스만 변경해주면 됩니다. spec: rules: - host: myapp.com http: paths: - path: / pathType: Prefix backend: service: name: myapp-green port: number: 80기존에는 myapp-blue 서비스가 연결되어 있었다고 할 때, myapp-green를 위한 Service와 Deployment를 만들고, Ingress에서 위 yaml과 같이 myapp-green로 만 변경해주면 되요.그리고 ingress 는 트래픽 제어를 Nginx를 사용할 때 주로 사용합니다. 작은 규모에서 쿠버네티스를 시작할 때 Nginx를 쓰는 게 간편하고요. Nginx에 설정을 반영시키기 위한 용도로 ingress를 사용하는 거죠. 하지만 규모가 커지면 Nginx와 ingress로는 부족 할 수 있습니다. 점점 다양하고, 섬세한 배포 방식도 요구 되면서 그에 맞는 트래픽 제어 컨트롤러들이 사용되고요. 이때부터는 Istio나 Traefik, Linkerd 등이 필요해져요. 어떤 걸 선택해야 할지는 또 상황에 따라 다르다는 점이 있고요.그런 부분에 있어서 Nginx는 트래픽 제어나 배포를 위한 첫 번째 단계라고 할 수 있습니다.

강사님 인그레스와 관련하여 질문 드립니다.

대략 아래와 같은 매커니즘으로 돌아갑니다. 1 : 사용자가 Ingress 리소스를 생성2 : Ingress Controller(Nginx)가 Ingress 리소스를 watch 받아, Path, Endpoint 등 필요한 설정 정보 확인3 : 감지된 정보를 기반으로 Nginx내부에 설정 템플릿을 생성4 : Nginx로 트래픽이 들어오면 내부 설정(Path)에 따라 연결된 Pod(Endpoint)로 전송결국 Nginx가 Kubernetes API Server를 통해 Ingress, Service, Endpoint등 필요한 정보들을 watch 받거나 조회 한다고 보시면 되요.

cat join.sh시 존재하지 않는다네요

안녕하세요.위에 하신 것 처럼 [root@k8s-master ~]# kubeadm token create --print-join-command를 하면 kubeadm join 192.168.56.30:6443 --token bver73.wda72kx4afiuhspo --discovery-token-ca-cert-hash sha256:7205b3fd6030e47b74aa11451221ff3c77daa0305aad0bc4a2d3196e69eb42b7이런 결과가 출력 됐습니다. 이다 master로 연결하는 토큰이고요.그럼 kubeadm join 192.168.56.30:6443 시작되는 내용을 쭉 복사해서 워커노드1 과 2에 붙여 넣으시면 되세요.

Loki 아키텍처 관련

loki와 grafana, promethues는 모두 독립적인 제품입니다. 그리고 함께 배포되는 건 누가 어떤 목적에 따라 helm 패키지를 구성했냐 차이라서, 항상 고정적이지 않아요. 모두가 함께 배포되게 만들 수도 있고, 각각 독립적으로 배포되게 만들 수 도 있습니다. 그리고 loki는 app 로그 수집이 목적이고, 프로메테우스는 노드 뿐만 아니라 쿠버네티스 내의 모든 메트릭을 수집하는 용도 입니다. 그래서 프로메테우스는 로깅 시스템 범주보단 메트릭 수집 및 모니터링 도구라고 보시면 되요.