쿠버네티스

[K8s] 쿠버네티스 livenessProbe로 파드 헬스 체크

쿠버네티스가 아니더라고 배포방식에서 헬스체크는 중요하다 블루그린으로 배포를 한다는 가정하에 먼저 was가 블루 일때 새로운 was그린을 배포하게된다 이과정에서 그린의 status code가 200이여야만 블루로 가있던 트레픽을 그린으로 옮기는것이다 만약 200인걸 확인 하는 health check가 없다면 status code가 500이더라도 그린으로 배포되는 상황이 오게된다 물론 개인 프로젝트라면 상관없겠지만 실제 서비스라면 끔찍한 일이다 이상태를 확인 할 수 있도록 쿠버네티스에선 livenessProbe기능이 존재한다 livenessProbe으로 헬스체크할 프로토콜로는 HTTP와 TCP, 명령으로 테스트하는 유형이 존재하는데 이번 포스팅에서는 HTTP프로토콜로 livenessProbe기능을 사용해보려..

[K8s] 쿠버네티스 Service 개념

Service란 무엇인가? Kubernetes 서비스는 파드의 논리적 집합과 파드에 액세스하기 위한 정책을 정의하는 추상화다. 서비스를 사용하면 응용프로그램의 다른 부분이나 외부 클라이언트에 응용프로그램의 기능을 노출할 수 있다. 서비스는 포드에 트래픽을 로드 밸런싱하는 데 사용할 수 있으며 포드에 안정적인 DNS 이름 및 네트워크 정책을 제공하는 데도 사용할 수 있다. Kubernetes에서 서비스는 서비스 유형, 서비스가 수신해야 하는 포트 및 서비스가 대상으로 해야 하는 포드를 지정하는 YAML 파일에 의해 정의된다. 그런 다음 서비스는 로드 밸런서를 생성하고 클러스터 내부 또는 외부에서 서비스에 액세스하는 데 사용할 수 있는 안정적인 IP 주소 및 DNS 이름을 할당한다. 예를 들어, 여러 포드로..

[K8s] 쿠버네티스 Deployment를 이용한 RollingUpdate

Deployment RollingUpdate를 설명하기에 앞서 무중단 배포에 대해서 얘기 좀 해보겠다 무중단 배포 DevOps에서 말하는 CI&CD 지속적 통합 지속적 배포이다 예를 들자면 쇼핑몰의 서비스를 진행 중인데 고객 관련 로직을 수정을 해서 WAS를 업데이트 즉 새로운 버전으로 배포를 해야 한다 하지만 업데이트 시점에 구 버전을 다운시키고 신 버전을 업 시키게 되면 그 중간에 트래픽 전송을 못하는 시점이 생겨버린다 이 시간에 만약에 쇼핑몰을 이용한다면 어떻게 될까 쇼핑몰을 이용하는 사용자는 원활하게 서비스를 이용하지 못하며 서비스 운영자는 그 시간에 거래가 불가능하기에 금전적 손실이 어마어마하게 발생할 것이다 위의 예시는 조금 최악의 상황을 가정하여 들은 예시지만, 충분히 있을 법한 예시이다. ..

[K8s] 쿠버네티스 Deployment의 개념

Deployment 디플로이먼트(Deployment)는 파드와 레플리카셋(ReplicaSet)에 대한 선언적 업데이트를 제공한다. 디플로이먼트에서 의도하는 상태를 설명하고, 디플로이먼트 컨트롤러(Controller)는 현재 상태에서 의도하는 상태로 비율을 조정하며 변경한다. 새 레플리카셋을 생성하는 디플로이먼트를 정의하거나 기존 디플로이먼트를 제거하고, 모든 리소스를 새 디플로이먼트에 적용할 수 있다. 사용 사례 레플리카셋을 롤아웃 할 디플로이먼트 생성. 레플리카셋은 백그라운드에서 파드를 생성한다. 롤아웃 상태를 체크해서 성공 여부를 확인한다. 디플로이먼트의 PodTemplateSpec을 업데이트해서 파드의 새로운 상태를 선언한다. 새 레플리카셋이 생성되면, 디플로이먼트는 파드를 기존 레플리카셋에서 새로..

[K8s] 쿠버네티스 ReplicaSet의 개념

ReplicaSet은 Pod 복제본을 생성하고 관리한다 더 이상 N개의 Pod을 생성하기 위해 생성명령을 N번실행할 필요가 없다 ReplicaSet오브젝트를 정의하고 원하는 Pod의 개수를 replicas속성으로 선언한다 클러스터관리자대신 Pod수가부족하거나 넘치지 않게 Pod 수를 조정 레플리카셋을 사용하는 시기 쿠버네티스 공식 docs에서 말하는 레플리카셋은 지정된 수의 파드 레플리카가 항상 실행되도록 보장한다. 그러나 디플로이먼트는 레플리카셋을 관리하고 다른 유용한 기능과 함께 파드에 대한 선언적 업데이트를 제공하는 상위 개념이다. 따라서 우리는 사용자 지정 오케스트레이션이 필요하거나 업데이트가 전혀 필요하지 않은 경우라면 레플리카셋을 직접적으로 사용하기보다는 디플로이먼트를 사용하는 것을 권장한다...

[K8s] 쿠버네티스 Label과 Selector

Label 쿠버네티스 오브젝트를 식별하기 위한 key:value 쌍의 메타데이터이다 Selector Label을 이용해 쿠버네티스 리소스를 필터링하고 원하는 리소스 집합을 구하기 위한 label query이다 그렇다면 언제 필요한가 한번 아래의 그림으로 설명해보겠다쿠버네티스 상에서 실행되고 있는 모든 Pod라고 할 때 사실 이 Pod들의 구분은 경계가 없다 그래서 예를 들어보면 내가 주문요청을 지정된 주문 Pod으로만 리다이렉트 하고 싶다 할 때 어떤 Pod이 주문 Pod인지 정의할 수 있어야 한다 일종의 주문 Pod의 집합이라고 생각하면 되겠다 또한 똑같이 주문요청이 있다면 배달 요청도 있을 텐데 똑같이 배달 Pod 들의 경계 즉 집합을 만들어주면 된다 이런 식으로 쿠버네티스에 많은 리소스들이 있는데..

[K8s] 쿠버네티스 Pod간의 네트워크

1. Pod안에 서로 다른 컨테이너끼리 localhost로 통신한다 하나의 Pod에 서로 다른 포트로 컨테이너 2개를 선언 2. 서로 다른 Pod끼리 Pod IP로 통신한다. Pod A에 있는 컨테이너 -> Pod B에 있는 컨테이너로 요청 전송/응답 확인 (파드 안에서 실행될 컨테이너는 준비되어있는 이미지이다) 진행 순서를 다시 한번 확인해 보자면 Pod 선언과 환경변수 설정 Pod 생성/배포 Pod IP 할당 및 컨테이너 실행 확인 컨테이너 환경변수 목록 확인 컨테이너 간 localhost 통신 다른 Pod의 Pod IP로 통신 포트포워딩을 통해 각 컨테이너로 요청/응답 확인 컨테이너 안에서의 엔드포인트 응답은 /sky, /tree, /rose, /hello 4개의 엔드포인트로 확인해볼 거다 총 실행..

[K8s] 쿠버네티스 Pod의 개념과 환경변수

파드(Pod)는 쿠버네티스에서 생성하고 관리할 수 있는 배포 가능한 가장 작은 컴퓨팅 단위이다. 파드 (고래 떼(pod of whales)나 콩꼬투리(pea pod)와 마찬가지로)는 하나 이상의 컨테이너의 그룹이다. 이 그룹은 스토리지 및 네트워크를 공유하고, 해당 컨테이너를 구동하는 방식에 대한 명세를 갖는다. 파드의 콘텐츠는 항상 함께 배치되고, 함께 스케줄 되며, 공유 콘텍스트에서 실행된다. 파드는 애플리케이션 별 "논리 호스트"를 모델링한다. 여기에는 상대적으로 밀접하게 결합된 하나 이상의 애플리케이션 컨테이너가 포함된다. 클라우드가 아닌 콘텍스트에서, 동일한 물리 또는 가상 머신에서 실행되는 애플리케이션은 동일한 논리 호스트에서 실행되는 클라우드 애플리케이션과 비슷하다. 쿠버네티스 공식 docs..