악분의 블로그

영상: https://youtu.be/27vM4Wa97ow code-server를 https로 배포해야하는 이유 code-server를 쿠버네티스 pod로 배포하면 https프로토콜을 사용하는 편이 좋습니다. https를 사용하지 않으면 몇몇 기능이 동작안할 수 있습니다. code-server에 접근하기 위해 웹 브라우저를 사용해야 합니다. 그리고 웹 브라우저 설정에 code-server기능에 영향을 받게 되고 웹 브라우저의 보안설정때문에 웹 브라우저에서 http프로토콜로 동작하는 기능을 실행 못할 수 있습니다. 대표적인 예가 ipynb파일을 열수 없습니다. 자세한 아키텍처를 모르겠지만 ipynb파일을 여는 기능이 webview로 되어 있지 않을까 생각합니다. ipynb파일을 열면 아래 그림과 같이 아무..

영상: https://youtu.be/If03sN4isO4 Headless서비스란? Headless서비스는 ClusterIP가 없는 서비스입니다. kubectl로 서비스를 조회하면 ClusterIP가 None으로 표시됩니다. Headless서비스와 일반 서비스 비교 Headless서비스는 kube-proxy가 처리하지 않아서 “서비스”를 이용한 로드 밸런싱 기능은 지원하지 않습니다. 일반 서비스는 kube-proxy가 처리하므로 서비스가 트래픽을 로드밸런싱 합니다. 하지만 headless서비스는 서비스를 거치지 않고 pod에 직접 접근합니다. DNS 쿼리 테스트 테스트를 하기 위해 제 git repo에 있는 쿠버네티스를 배포합니다. kustomize를 이용하여 쉽게 배포할 수 있습니다. 배포가 성공하면 ..

개요 A팀이 프록시 목적으로 띄운 nginx pod가 취약점이 있어 수정하라고 요구받았습니다. A팀은 nginx pod설정을 고쳐도 권고받은 취약점이 사라지지 않아 저에게 도움을 요청했습니다. 분석 취약점은 405 method not allowd를 에러로 처리하지 않고 그대로 노출시켰다는 것입니다. default 405응답에는 nginx문자이 있었습니다. A팀은 405예외 처리를 했지만 계속 취약점이 발생했습니다. 저는 쿠버네티스라는 환경과 오류응답에 nginx라는 키워드를 보고 nginx ingress controller오류이지 않을 까 생각했습니다. 그래서 먼저 ingress controller가 nginx인지 먼저 확인했습니다. 예상대로 nginx였습니다. 그 다음, nginx ingress con..

오늘 회의를 하다가 컨테이너 로그 수집기준에 대해 잠깐 이야기하는 상황이 있었습니다. 이야기 내용이 매우 흥미로웠습니다. 회의 끝에 가장 중요한 기준은 "유실유무"였습니다. 유실되어도 실시간이 중요하다 유실되면 안되고 신뢰성이 중요하다 컨테이너가 갯수가 기하급수적으로 늘어나면 로그 수집에 장애가 생겨 일부 로그가 수집이 안될 수 있습니다. 물론 장애를 완벽히 고치면 좋겠지만, 인원이 한정되어 있고 다른 업무의 우선순위가 높으면 임시적으로 장애를 고칠 수 밖에 없습니다. 그래서 회의에서 "유실유무"라는 기준이 이야기 나왔습니다. 신뢰성이 중요하다면 아키텍처를 확인하고 완충장치(예: 카프카)를 넣기로 검토하기로 했습니다.

영상: https://youtu.be/ZHBkvNVtpIA 개요 helm hook은 helm 차트 라이플 사이클을 이용하여, 사용자가 원하는 동작을 추가하는 기능입니다. pod, configmap 등 쿠버네티스 리소스에 annotation을 설정하여 helm hook을 구현할 수 있습니다. apiVersion: batch/v1 kind: Job metadata: name: test annotations: "helm.sh/hook": post-install ... 종류 helm install, delete, upgrade, delete, test에 hook을 할 수 있습니다. 각 기능이 동작하기 전/후로 hook을 추가할 수 있습니다. 자세한 내용은 공식문서를 참고하시길 바랍니다. 주의사항 helm hoo..

aws eks update-kubeconfig --region {region 이름} --name {cluster 이름}