서비스의 타입은 ClusterIP, NodePort, LoadBalancer, ExternalName 네 가지가 있습니다. 이들은 어떻게 다른가?

쿠버네티스 ServiceTypes는 원하는 서비스 종류를 지정할 수 있도록 해준다. 기본 값은 ClusterIP이다.

📌 Type 값과 그 동작은 다음과 같다.

• ClusterIP:
  (Default)service type 서비스를 클러스터-내부 IP에 노출시킨다.
  이 값을 선택하면 클러스터 내에서만 서비스에 도달할 수 있다.
  이것은 ServiceTypes의 기본 값이다

• NodePort:
  고정 포트 (NodePort)로 각 노드의 IP에 서비스를 노출시킨다.
  NodePort 서비스가 라우팅되는 ClusterIP 서비스가 자동으로 생성된다.
  NodeIP:NodePort 를 요청하여, 클러스터 외부에서 NodePort 서비스에 접속할 수 있다.

• LoadBalancer:
  클라우드 공급자의 로드 밸런서를 사용하여 서비스를 외부에 노출시킨다.
  외부 로드 밸런서가 라우팅되는 NodePort와 ClusterIP 서비스가 자동으로 생성된다.

• ExternalName:
  값과 함께 CNAME 레코드를 리턴하여, 서비스를 externalName 필드의 콘텐츠 (예:foo.bar.example.com)에 매핑한다. 어떤 종류의 프록시도 설정되어 있지 않다.

probe의 종류

💡 Probe (참고)
쿠버네티스에서는 다양한 종류의 probe를 지원한다. probe는 kubelet에서 현재 노드에서 실행중인 컨테이너의 상태를 파악하고 라이프사이클을 제어하는 health-check 기능을 수행 한다.

❓ kubelet은 컨테이너의 상태를 진단하기 위해 핸들러를 호출하는데, 핸들러는 수행하는 작업의 분류에 따라 구분된다.

1. ExecAction - 컨테이너 내에서 지정된 명령어를 실행한다. 명령어 상태 코드 0으로 종료되면 진단이 성공한 것으로 간주한다.
2. TCPSocketAction - 지정된 포트에서 컨테이너의 IP 주소에 대해 TCP 검사를 수행한다. 포트가 활성화되어 있다면 진단이 성공한 것으로 간주한다.
3. HttpGetAction - 지정된 포트 및 경로에서 컨테이너의 IP 주소에 대한 HTTP Get 요청을 수행한다. 응답의 상태코드가 200 보다 크고 400 보다 작으면 진단이 성공한 것으로 간주한다.

kubelet은 실행 중인 컨테이너에 대해서 세 가지 종류의 프로브가 있다.

• Liveness probe
  애플리케이션의 상태를 체크해서 서버가 제대로 응답하는지 혹은 컨테이너가 제대로 동작 중 인지를 검사한다. Pod은 정상적인 Running 상태이지만, 애플리케이션에 문제가 생겨서 접속이 안되는 경우를 감지한다. (메모리 오버플로우 등) 문제를 감지하면 Pod을 죽이고 재실행하여 애플리케이션의 문제를 해결한다.

• Readiness probe
  컨테이너가 요청을 처리할 준비가 되었는지 확인하는 probe이다. Pods 가 새로 배포되고 Running 상태여도 처음에 로딩하는 시간이 있기 때문에 이 시간 동안은 애플리케이션에 접속하려고 하면 오류가 발생한다. Readiness probe는 어플리케이션이 구동되기 전까지 서비스와 연결되지 않게 해준다. (Readiness Probe가 실패할 때 엔드포인트 컨트롤러가 파드에 연관된 모든 서비스들의 엔드포인트에서 파드의 IP주소를 제거한다. ) Liveness Probe와 비교했을 때 어떤 차이가 있냐면, Liveness Probe는 probe 핸들러 조건 아래 fail이 나면 pod을 재실행 시키지만 Readiness Probe는 pod을 서비스로부터 제외시킨다.

• Startup probe
  컨테이너 내의 애플리케이션이 시작되었는지를 나타낸다. startup probe가 주어진 경우, 성공할 때 까지 다른 나머지 prob는 활성화 되지 않는다. 만약 startup probe가 실패하면, kubelet이 컨테이너를 죽이고, 컨테이너는 재시작 정책에 따라 처리된다.

각 probe를 언제 사용 해야할까?

• Liveness Probe (활성 프로브)
  만약 컨테이너 속 프로세스가 어떠한 이슈에 직면하거나 건강하지 못한 상태(unhealthy)가 되는 등 프로세스 자체의 문제로 중단될 수 있더라도, 활성 프로브가 반드시 필요한 것은 아니다. 이러한 경우에는 kubelet이 파드의 재시작 정책(restart policy)에 따라서 올바른 대처를 자동적으로 수행한다.
  프로브가 실패한 후 컨테이너가 종료되거나 재시작 되기를 원한다면, 활성 프로브를 지정하고, 재시작 정책을 항상(Always) 또는 실패 시(OnFailure)로 지정한다.

• Readiness Probe (준비성 프로브)
  probe가 성공한 경우에만 파드에 트래픽 전송을 시작하려고 한다면 Readiness probe를 지정하면 된다. 왜냐하면 그전까지는 애플리케이션이 로드되지 않은 상황에서도 트래픽이 해당 애플리케이션으로 라우팅될 수 있기 때문이다.
  혹은 컨테이너의 지속적인 유지 및 관리를 위해서 자체적으로 중단을 수행하는 경우는 pod을 죽이는 Liveness probe말고 Readiness probe를 사용할 수 있다.

• Startup Probe (시작 프로브)
  서비스를 시작하는 데 오랜 시간이 걸리거나 불규칙적인 컨테이너에 설정하는 데 사용될 수 있다.(예를 들면 third party 에서 특정 데이터를 다운받는 등의 경우) startup probe가 성공하고 나서 liveness, readiness probe가 동작하기 때문에 기동시간이 불규칙적인 애플리케이션이 liveness probe에 의해 기동되기도 전에 재시작 되는 것을 방지할 수 있다.(Readiness probe랑 비슷하지만 방금 말한 부분은 Readiness probe로 해결하기 어렵다)

왜 파드와 PV(퍼시스턴스볼륨)를 직접 연결하지 않는걸까요?

수동 연결이 안되는거는 아니지만 스토리지 제공자를 수동으로 호출하여 새 스토리지 볼륨을 생성한 다음 Kubernetes에서 이를 나타내는 PersistentVolume 객체를 생성해야 하기 때문에 pvc를 사용하는것 일반적이다.
pvc를 이용하면 사용자는 pv를 연결할 때 어떤 스토리지를 사용하는지 신경 쓰지 않아도 사용자가 요청할 때 자동으로 스토리지를 프로비저닝합니다.
그외에도 파드가 볼륨의 세부 사항을 몰라도 볼륨을 사용할 수 있게 도와줍니다.