Passwd

개요최근 오랜만에 쿠버네티스 관련 작업을 담당하게 되었는데, pdb라는 리소스를 새로 알게 되었다. 확인해보니 가용성, pod 중단 등과 관련이 있는 개념인 것 같다. 관련해서 알아두는 게 좋을 것 같아 정리해둔다. 중단Pod는 사람 또는 컨트롤러가 파괴하거나 불가피한 하드웨어/시스템 소프트웨어 오류가 발생한 경우가 아니라면 사라지지 않는다. 이 때 사람 또는 컨트롤러가 파괴한 경우를 자발적 중단이라고 하고, 오류로 인한 불가피한 중단을 비자발적 중단이라고 한다.각 중단이 발생할 수 있는 상황의 예시는 다음과 같다.자발적 중단비자발적 중단Deployment 제거물리 머신 하드웨어 오류다른 Pod를 관리하는 컨트롤러 제거클러스터 관리자 실수에 의한 VM 삭제Deployment 템플릿 업데이트클라우드 공..

개요최근 쿠버네티스 환경을 다루면서 Helm으로 설치한 서비스를 재배포하는 등의 작업을 수행하게 됐다. 하지만 재배포 이후에도 수정한 설정값으로 리소스가 생성되지 않은 것 같아서 배포에 사용한 values.yaml과 Chart가 결합된 release 정보를 확인하고 싶다.방법을 알아보자. 릴리즈 정보 확인이미 배포한 릴리즈의 정보는 get manifest 명령어로 확인할 수 있다.매니페스트란 차트에서 생성된 쿠버네티스 리소스를 yaml 형식으로 표현한 것이다. helm get manifest RELEASE_NAME# 예시helm get manifest superset Chart + value.yaml 확인로컬 환경에서 Chart를 렌더링 하고 그 결과를 표시한다. 사용할 values.yaml을 지정하..

현상AWS EKS의 NodeGroup LT 업데이트로 인해 노드 재시작이 발생했는데, Jenkins 서비스가 시작하던 중 플러그인 버전 충돌이 발생해 Jenkins 버전 업그레이드를 진행하려고 한다.Jenkins Helm Chart(https://charts.jenkins.io)의 4.6.1 버전에서 5.1.0 버전으로 업그레이드를 진행하려고 했는데…… helm upgrade 중 아래와 같이 오류가 발생하면서 업그레이드가 되지 않았다.원인을 확인하고 문제를 해결해 보자. 원인확인해 보니 Chart Templete과 매핑하고자 하는 values.yaml의 데이터 형식 등이 맞지 않을 때, 매핑되지 않는 값을 전달하거나 list를 전달해야 하는데 dictionmary를 전달하는 등의 상황일 때 발생하는 ..

현상AWS EKS 환경에서 Jenkins를 Helm으로 설치해서 동작시키고 있는데, 서비스가 종료되었다가 재시작하면서 동작을 안 하고 있는 상태이다.대체로 단순 서비스 재시작 시 Jenkins가 정상적으로 올라오지 않는 상황은 Jenkins 버전과 플러그인 버전 충돌이 원인일 수 있다.관련해서 확인하고 해결할 수 있는 부분을 적어둔다. 참고로 구성은 다음과 같다.쿠버네티스 클러스터 / 버전 : AWS EKS / kubernetes 1.27.6Helm Chartrepository : https://charts.jenkins.iochart version : 4.6.1app version : 2.414.1 describe플러그인 버전 충돌이 발생하면 대체로 플러그인 설치가 진행되는 initContainer..

현상AWS EKS로 구성된 쿠버네티스 클러스터를 운영하고 있는데, 인프라 운영팀으로부터 NodeGroup과 연결된 Launch Templete의 리소스 태그 변경이 필요하다는 연락을 받았다. LT를 업데이트하면 기존에 동작하고 있던 Node가 종료되면서 새로운 버전의 LT로 만들어진 Node가 생성되기 때문에 서비스 확인 등의 작업이 필요한 상황이었다. 1년 정도 유지보수를 하지 않다가 작업한 상황이라 걱정이 되었는데, 아니나 다를까 작업 후 Helm으로 설치한 Superset에서 아래와 같은 오류가 발생했다.원인을 파악하고 문제를 해결해보자. 참고로 현재 환경은 다음과 같다.쿠버네티스 클러스터 / 버전 : AWS EKS / kubernetes 1.27.6Helm Chartrepository : http..

개요2024.05.22-[K8s] 네트워크 유형 - Pod와 Service 간 통신에서는 Service의 개념과 동작 방식에 대해서 알아보았다. 다만 Service는 기본적으로 ClusterIP 유형으로 생성되어 클러스터 내부에서만 통신이 가능하도록 되어있다. 그렇다면 외부와 통신을 주고받아야 할 때는 어떻게 해야 할까? 쿠버네티스에서는 NodePort 유형의 Service, Load Balancer 유형의 Service 그리고 Ingress를 통해 외부와의 통신을 가능하게 한다.각각에 대해서 정리해 둔다.   NodePortNodePort 유형의 Service는 기본적으로 Cluster IP 유형과 비슷하지만, Node 네트워크의 IP를 통한 접근을 허용하는 등의 몇 가지 기능을 더 갖고 있다. 즉, ..

개요2024.05.18-[K8s] 네트워크 유형 - 컨테이너 간 통신, 2024.05.19-[K8s] 네트워크 유형 - Pod 간 통신에서 쿠버네티스의 4가지 통신 유형 중 2가지 유형을 살펴보았다. 이번 글에서는 Service의 개념과 Pod과 Service 간 통신에 대해 적어두려고 한다.  ServicePod는 각각의 고유한 주소를 가지기 때문에 어떤 애플리케이션의 엔드포인트로 설정할 수도 있다. 하지만 쿠버네티스에서 Pod는 쉽게 대체되기 때문에 새로 생성된 Pod의 주소가 기존 Pod와 동일함을 보장하지 않는다.이러한 문제를 해결하기 위해 애플리케이션 앞에 서버의 목록을 관리하며 서비스 중인 서버에게 트래픽을 전달하는 reverse-proxy나 load balancer를 구성할 수 있다. 이러한..

개요2024.05.18-[K8s] 네트워크 유형 - 컨테이너 간 통신에서는 도커, 쿠버네티스 환경에서의 컨테이너 간 통신에 대해서 정리했다.이번 글에서는 Pod 간 통신에 대한 내용을 적어두려고 한다. Pod 간 통신은 단일 노드에서의 통신 그리고 멀티 노드에서의 통신으로 구분할 수 있다.  단일 노드에서의 Pod쿠버네티스의 Pod는 고유한 IP 주소(veth)를 가지므로, IP 주소로 서로 통신할 수 있다.쿠버네티스는 kubenet이라는 기본적이고 간단한 네트워크 플러그인을 제공한다. 다만 kubenet에는 노드 간 네트워킹, 네트워크 정책 설정과 같은 고급 기능은 구현되어 있지 않기 때문에 Calico, Flannel 등과 같은 CNI 기반 네트워크 플러그인 사용을 권장하고 있다. 일례로 kudead..

개요쿠버네티스에서 네트워크는 크게 컨테이너 간 통신, Pod 간 통신, Pod와 서비스 간 통신, 외부와 서비스 간 통신으로 나누어진다.쿠버네티스 환경에서 작업하다 보면 네트워크 관련으로 항상 헤매게 되는 것 같아서 정리해두려고 하는데, 그전에 먼저 네트워크 유형에 대해 정리해보려고 한다.   도커먼제 도커 환경에서 기본적인 네트워크 동작을 알아본다.도커 환경에서 같은 호스트에 존재하는 컨테이너 간의 통신은 docker0이라는 가상 네트워크 인터페이스를 통해 이루어진다. docker0은 호스트 네트워크 인터페이스 또는 디폴트 네트워크 네임스페이스라고 칭해진다.그리고 각 컨테이너는 veth라는 고유한 가상 네트워크 인터페이스를 가지기 때문에 각각의 veth IP주소로 통신한다.컨테이너 내에서는 네트워크 네..

개요<p data-ke-..