- [C183] 애플리케이션에 HTTP 500과 같은 에러가 발생한 경우, 컨테이너를 다시 실행해야 할 것 입니다. HTTP 에러가 발생했다는 것을 어떻게 알 수 있을까요? 어떻게 해야 쿠버네티스가 에러가 발생한 컨테이너를 자동으로 재시작하게 만들 수 있을까요? (힌트: liveness probe 키워드를 검색하세요)
프로브는 컨테이너에서 kubelet에 의해 주기적으로 수행되는 진단(diagnostic)이다. 진단을 수행하기 위해서, kubelet은 컨테이너 안에서 코드를 실행하거나, 또는 네트워크 요청을 전송한다.
프로브 종류
Liveness Probe
Liveness Probe는 컨테이너가 제대로 실행중인지 확인하고 실패 임계값에 도달하면 컨테이너를 종료한다. 대부분 경우 컨테이너의 재시작 정책에 따라 Kubernetes는 실패한 컨테이너를 자동으로 재시작한다. 복구 가능성이 없는 상태에서 고장이 발생할 수 있는 컨테이너에 Liveness Probe를 사용할 수 있다.
Readiness Probe
Readiniess probe는 컨테이너가 새 요청에 응답을 할 준비가 되었는지를 확인하며 Liveness Probe와 달리 Readiniess Probe는 컨테이너를 종료하지 않는다. Kubernetes는 해당 서비스에서 컨테이너의 포드를 제외시키며 트래픽이 리디렉션되지 않도록 한다. 또한 Readionsee Probe가 성공해야 트래픽을 보내기 시작한다.
Startup Probe
Startup Probe는 컨테이너 내 어플리케이션이 제대로 시작되었는지 확인한다. Startup Probe는 다른 두가지 프로브 유형보다 우선순위가 높아 성공할 때 까지 다른 나머지 프로브는 활성화되지 않는다. 만약 Startup Probe가 실패한 경우 컨테이너의 재시작 정책에 따라 Kubernetes는 실패한 컨테이너를 자동으로 재시작한다. Startup Probe는 앱을 시작하는 데 오랜 시간이 걸리거나 가끔 시작 시 실패할 수 있는 상황에서 유용하다.
체크 메커니즘
프로브를 사용하여 컨테이너를 체크하는 방법에는 4가지가 있다. 각 프로브는 다음의 4가지 메커니즘 중 단 하나만을 정의해야 한다.
Exec
컨테이너 내에서 지정된 명령어를 실행하며 명령어가 상태 코드 0으로 종료되면 진단이 성공한 것으로 간주한다.
gRPC
gRPC를 사용하여 원격 프로시저 호출을 수행한다. 체크 대상이 gRPC 헬스 체크를 구현해야 한다. 응답의 status 가 SERVING 이면 진단이 성공했다고 간주한다. gRPC 프로브는 알파 기능이며 GRPCContainerProbe 기능 게이트를 활성화해야 사용할 수 있다.
gRPC는 Google에서 개발한 RPC(Remote Procedure Call) 시스템입니다. 전송을 위해 TCP/IP 프로토콜과 HTTP 2.0 프로토콜을 사용하고 IDL(Interface Definition language)로 protocol buffer를 사용합니다.
HttpGet
지정한 포트 및 경로에서 컨테이너의 IP주소에 대한 HTTP GET 요청을 수행하며 응답의 상태 코드가 200 이상 400 미만이면 진단이 성공한 것으로 간주한다.
TcpSocket
지정된 포트에서 컨테이너의 IP주소에 대해 TCP 검사를 수행하며 포트가 활성화되어 있다면 진단이 성공한 것으로 간주한다. 원격 시스템(컨테이너)이 연결을 연 이후 즉시 닫는다면, 이 또한 진단이 성공한 것으로 간주한다.
즉, Liveness Probe와 HttpGet 메커니즘을 사용하면 500 에러가 났을 때 Always가 디폴트 값인 재시작 정책에 따라 자동으로 재시작할 것이며 500번 에러를 확인하는 방법은 아래 명령어를 쓰면 된다.
kubectl describe <리소스종류> <리소스이름> 
https://chacha95.github.io/2020-06-15-gRPC1/
https://www.padok.fr/en/blog/kubernetes-probes
- [C184] 왜 파드와 PV(퍼시스턴스볼륨)를 직접 연결하지 않는걸까요?
볼륨
파일이나 데이터베이스에 데이터가 저장되기 위해서는 물리적인 스토리지가 있어야 하며 이러한 물리적인 스토리지를 파티션으로 나눈 후 읽고 쓰기가 가능하게 만든 저장 영역을 볼륨이라고 한다.
쿠버네티스 환경에서는 모든 어플리케이션이 파드안에 컨테이너로 실행이 되기에 물리 머신이나 가상 머신에 실행되는 어플리케이션이 볼륨을 사용하는 방법과는 차이가 날 수 밖에 없다.
컨테이너는 언제라도 사라질 수 있기 때문에 컨테이너가 사라지면 당연히 내부 볼륨도 없어지고 그럼 소중한 데이터를 잃어 버릴 수 있다.
따라서 데이터를 안전하게 보존하면서 읽고 쓰기 위해서 외부 볼륨이 필요하다.
볼륨을 크게 나누면 파드 로컬 볼륨, 노드 로컬 볼륨, 네트워크 볼륨으로 나눌 수 있으며 이는 공식적인 것이 아닌 이해를 돕기 위해 임의적으로 나눈 분류이다. 파드 로컬 볼륨은 파드 안에만 만들어지는 볼륨이고 노드 로컬 볼륨은 쿠버네티스 클러스터 노드의 볼륨이며 네트워크 볼륨은 클러스터 외부에 존재하는 볼륨이다.
파드가 볼륨을 사용하는 목적을 어플리케이션과 데이터베이스 관점에서 나눠보고 거기에 맞는 볼륨 유형을 정리하면 아래와 같다.
파드가 어떻게 볼륨을 사용하는 지에 핵심적인 방법은 ‘마운트'이다.
파드내에 볼륨을 ‘마운트'함으로써 어떤 유형의 볼륨이든 상관 없이 마치 파드 내부의 파일 시스템인것처럼 사용할 수 있게 된다.
하지만 이러한 아키텍처는 치명적인 문제가 있다.
바로 쿠버네티스와 인프라스트럭처가 너무 강결합이 되어 버려 스토리지 제품의 변화나 스토리지 서버의 변화가 파드에 직접적인 영향을 미치게 된다. 또한 파드 명세를 정의하는 사람은 스토리지에 대한 어느 정도의 지식이 필요하게되어 인프라스트럭처를 운영하는 사람에게 의존적이 될 수밖에 없게 된다.
이러한 문제점은 쿠버네티스와 인프라스트럭처를 중계자 역할을 만들어 느슨하게 결합시키면 해결할 수 있다. 쿠버네티스는 인프라스트럭처와의 느슨한 결합을 위해 퍼시스턴트 볼륨PV(Persistent Volume)/퍼시스턴트 볼륨 클레임 PVC(Persistent Volume Claim)와 CSIContainer Storage Interface라는 중계자 역할을 만들었으며 파드가 볼륨을 사용하는 아키텍처는 아래와 같은 모습이 된다.
Kubernetes PV(영구 볼륨)란 무엇일까?
Kubernetes 영구 볼륨(PV)은 Kubernetes 클러스터의 일부로 관리자가 제공하는 스토리지 단위이다. 노드가 클러스터에서 사용하는 컴퓨팅 리소스인 것처럼 PV는 스토리지 리소스입니다. PV는 이를 사용하는 포드의 수명 주기와 무관합니다. 즉, 포드가 종료되더라도 볼륨의 데이터는 지워지지 않는다. NFS 파일 공유 또는 특정 클라우드 스토리지 시스템과 같은 스토리지의 구현 세부 정보를 캡처하는 API 개체에 의해 정의됩니다.
Kubernetes PV 관리자가 제공한 볼륨이며. 파일 시스템, 크기 및 볼륨 ID 및 이름과 같은 식별자를 포함하여 사전 정의된 속성이 있다. 파드가 이러한 볼륨을 사용하기 시작하려면 지속 볼륨 클레임(PVC)을 발행하여 볼륨을 요청해야하며 PVC는 포드에 필요한 스토리지 용량 및 특성을 설명하고 클러스터는 요청을 일치시키고 원하는 영구 볼륨을 프로비저닝하려고 시도힌다.
PersistentVolumeClaim(PVC)란 무엇일까?
PVC는 저장을 위해 Kubernetes 노드에서 보낸 요청이다. 클레임에는 애플리케이션에 필요한 특정 스토리지 매개변수(예: 스토리지 양 또는 특정 유형의 액세스(읽기/쓰기, 읽기 전용 등))가 포함될 수 있다.
Kubernetes는 사용자의 PVC에 정의된 기준을 충족하는 PV를 찾고, 있는 경우 PV에 대한 클레임과 일치하며 이것을 바인딩이라고 합니다. 청구에 대해 PV를 동적으로 프로비저닝하도록 클러스터를 구성할 수도 있다.
Container Storage Interface(CSI)란 무엇일까?
CSI(Container Storage Interface)는 CNCF(Cloud Native Computing Foundation)에서 지원하는 이니셔티브이다. 컨테이너 영구 저장소의 사용을 표준화하기 위해 컨테이너화 기술 초기에 만들어졌으며 CSI는 다양한 저장 기술과 방법을 사용하여 단편화된 컨테이너 저장 기술의 문제를 해결하기 위한 것이었다.
CSI는 스토리지 시스템이 데이터를 컨테이너 오케스트레이터에 노출하는 방법과 오케스트레이션 플랫폼이 스토리지 장비에 연결되는 표준방법이며 CSI 호환 스토리지 시스템과 컨테이너 오케스트레이터 플랫폼은 CSI 프로세스를 사용하여 서로 통합할 수 있다. 현재 컨테이너 오케스트레이션 플랫폼과 잘 통합될 수 있는 100개 이상의 CSI 호환 스토리지 솔루션이 있으며 그 중 가장 인기 있는 것은 Kubernetes입니다. 따라서 CSI는 유연하고 관리 가능한 Kubernetes 스토리지 의 기반이다.
즉, PV는 클러스터 또는 중앙 스토리지(예: 100GB)의 스토리지이고 PVC는 애플리케이션이 10GB를 사용하기 위해 사용자가 저장을 요청하는 것이다.
PV는 전체 케이크이고 PVC는 조각 케이크입니다(그러나 다른 사람이 먹을 사람이 없으면 전체 케이크를 가질 수 있습니다(사용할 다른 응용 프로그램이 없는 경우 전체 PV를 사용할 수 있는 것처럼))
그래서 직접 연결할려면 파드내에 볼륨을 마운트를 해야하고 그러면 쿠버네티스와 인프라스트럭쳐가 강결합이 되기때문에 스토리지 서버의 변화가 파드에 직접적인 영향을 끼치게 된다. 이러한 의존도를 줄이기 위해, 퍼시스턴스 볼륨 클레임(Persistence Volume Claim, 이하 PVC)을 이용하여 PV와 연결한다.
https://cloud.netapp.com/blog/cvo-blg-container-storage-interface-the-foundation-of-k8s-storage
https://cloud.netapp.com/blog/kubernetes-persistent-storage-why-where-and-how