본문 바로가기

About/Kubernetes

(37)
[k8s] Liveness Probe - ExecAction을 이용한 Pod Health Check kubernetes에서는 HTTP Request나 TCP Socket와 같은 리퀘스트의 결과가 아니라 컨테이너 안에서 임의의 명령을 실행하여 그 결과로 파드의 가동 여부를 판단할 수 있습니다. 매니페스트 파일 작성 # pod-liveness-exec.yaml # 1. 기본 항목 apiVersion: v1 kind: Pod metadata: labels: test: liveness name: liveness-exec # 2. Pod Spec spec: # 3. Container 사양 containers: - name: liveness image: busybox # busybox args: - /bin/sh - -c - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy..
[k8s] Liveness Probe - HTTP Request를 이용한 Health Check(HTTPGetAction) 웹 애플리케이션의 경우 특정 URL에 HTTP 리퀘스트를 보내, 그 반환값을 체크함으로써 애플리케이션이 정상적으로 움직이고 있는지를 판단할 수 있습니다. 매니페스트 파일 작성 # 기본 항목 apiVersion: v1 kind: Pod metadata: labels: test: liveness name: liveness-http # Pod Spec spec: # Container spec containers: - name: liveness image: k8s.gcr.io/liveness args: - /server livenessProbe: httpGet: # Http 리퀘스트 반환 값에 따라 체크함 path: /healthz port: 8080 httpHeaders: - name: X-Custom-Hea..
[k8s] 파드의 우선순위(Pod QoS, Quality of Service) 쿠버네티스는 하나의 클러스터에서 여러 개의 컨테이너 애플리케이션을 실행할 수 있습니다. 하지만 예를 들어 '온라인 처리를 제공하는 컨테이너으 우선순위를 높이고 싶다', '배치 처리를 하는 리소스의 우선순위를 낮추고 싶다' 와 같은 조건을 주고 싶은 경우 QoS 클래스를 사용하여 파드에 우선순위를 붙일 수 있습니다. 파드의 QoS 클래스 조건 쿠버네티스에서는 파드에 대해 3개의 Quality of Service(QoS) 클래스를 제공하고 있습니다. 이 QoS는 Resource Requests와 리소스의 상한을 정하는 Resource Limits 조건을 바탕으로 우선순위가 다음과 같이 정해집니다. BestEffort 파드 안의 어떤 컨테이너에도 Resource Requests와 Resource Limit이 ..
[k8s] Probe - Pod Health Checks(readiness Probe vs liveness Probe) 쿠버네티스 클러스터 상에는 많은 파드가 가동됩니다. 이것들이 정상적으로 움직이고 있는지 아닌지를 체크해서 만일 문제가 있으면 재빨리 복구해야 합니다. 쿠버네티스에서는 컨테이너 애플리케이션이 올바르게 움직이고 있는지 아닌지를 항상 감시하여 문제가 있으면 파드를 자동으로 재시작하는 장치가 있습니다. 위 장치를 Probe라고 합니다. 즉 프로브(Probe)는 컨테이너에서 kubelet에 의해 주기적으로 수행되는 진단(diagnostic)입니다. 진단 방식(Probe)에는 다음 두가지 가 있습니다. livenessProbe 컨테이너가 실행됐는지 확인합니다. 이 진단이 실패하면 kubelet은 컨테이너를 종료시키고, restart 정책에 따라 컨테이너를 재시작합니다. 컨테이너에 liveness Probe를 어떻게..
[k8s] Pod LifeCycle(파드의 생명 주기) Pod LifeCycle 파드는 생성부터 삭제까지의 과정에 생명 주기(LiefCycle)이 있습니다. 파드의 생명 주기는 다음과 같습니다. 파드의 Status 값 설명 Pending 파드의 작성을 기다리고 있는 상태, 컨테이너 이미지의 다운로드 등에 시간이 걸리는 경우가 있습니다. Running 파드가 가동 중인 상태 Succeeded 파드 안의 컨테이너가 정상적으로 종료된 상태 Failed 파드 안의 컨테이너 중 하나의 컨테이너가 실패하여 종료된 상태 Unknown 어떤 이유로 파드와 통신할 수 없는 상태 파드는 Pending 단계에서 시작해서, 기본 컨테이너 중 적어도 하나 이상이 OK로 시작하게 되면 Running 단계를 통과하고, 그런 다음 파드의 컨테이너가 실패로 종료되었는지 여부에 따라 Suc..
[k8s] Job/CronJob Job/CronJob은 웹 서버와 같은 상주 서비스가 아니라 집계 등과 같은 배치 처리 또는 기계학습이나 수치해석과 같은 프로그램의 시작부터 종료까지로 완료되는 작업을 실행하기 위한 리소스입니다. Job(잡) 잡은 실행된 후 종료해야 하는 성격의 작업을 실행시킬 때 사용하는 컨트롤러입니다. 특정 개수만큼의 파드를 정상적으로 실행 종료함을 보장합니다. 예를 들어 데이터베이스 마이그레이션과 같이 한 번의 잡으로 처리가 끝나는 것에 이용합니다. 잡에서 하나 이상의 파드를 생성하고 지정된 수의 파드가 성공적으로 종료될 때 까지 계속해서 파드의 실행을 재시도합니다. 지정된 수 만큼 파드가 성공적으로 완료되면, 작업(즉, 잡)이 완료됩니다. 잡을 삭제하게되면 생성한 파드가 정리되며, 일시 중지하게 되면 작업이 다시..
[k8s] 데몬셋(Daemonset) 데몬셋(Daemonset) 데몬셋은 클러스터 전체 노드에 특정 파드를 실행할 때 사용하는 컨트롤러입니다. 클러스터 안에 새롭게 노드가 추가되었을 때 데몬셋이 자동으로 해당 노드에 파드를 실행시킵니다. 반대로 노드가 클러스터에서 빠졌을 때는 해당 노드에 있던 파드는 그대로 사라질 뿐 다른 곳으로 옮겨가서 실행되지는 않습니다. 따라서 데몬셋은 보통 로그 수집기를 실행하거나 노드를 모니터링하는 데몬 등 클러스터 전체에 항상 실행해두어야 하는 파드에 사용합니다. 데몬셋(Daemonset) 사용해보기 매니페스트 파일 작성 로그 수집을 실행하는 데몬셋의 예시는 다음과 같습니다. apiVersion: apps/v1 kind: DaemonSet metadata: name: fluentd-elasticsearch nam..
[k8s] 디플로이먼트(Deployment) 디플로이먼트 디플로이먼트(Deployment)는 쿠버네티스에서 상태가 없는(stateless) 앱을 배포할 때 사용하는 가장 기본적인 컨트롤러입니다. 쿠버네티스가 처음 등장했을 때는 Replication Controller에서 앱을 배포했는데 최근에는 디플로이먼트를 기본적적인 앱 배포에 사용합니다. Stateless Application이란? 클라이언트와 서버의 연결 구조에서 불필요한 상태의 반영을 위한 데이터나 리소스가 사용되지 않는 형태의 서비스 구조 파드와 레플리카셋은 '이력'이라는 개념이 없기 때문에 릴리스 후에 변경이 없는 애플리케이션을 관리하는데 적합합니다. 디플로이먼트는 이름처럼 배포 기능을 세분화 한 것으로 파드와 레플리카셋에 버전 관리 기능을 추가한 것이라고 생각하면 이해가 쉽습니다. 단..
[k8s] RelicaSet(레플리카셋) 정리 ReplicaSet 레플리카셋은 클러스터 안에서 움직이는 파드의 수를 유지하는 장치입니다. 클러스터의 파드의 실행을 항상 안정적으로 유지하는 것을 목표로 명시된 파드 개수에 대한 가용성을 보증하는데 사용됩니다. 만약 애플리케이션 오류나 노드 장애 등으로 파드가 정지된 경우 레플리카셋이 자동으로 새로운 파드를 시작합니다. 레플리카셋은 labelSelector의 조건에 따라 파드를 검색하여 가동 중인 파드의 수가 매니페스트 파일의 replicas의 수와 일치하는지 아닌지를 확인합니다. 만약 가동중인 파드의 수가 부족한 경우 새로 파드를 추가하고, 파드의 수가 많을 때는 여분의 파드를 정지시킵니다. 따라서 가동 중인 애플리케이션의 파드 수를 변경하고 싶을 때는 레플리카셋의 replicas의 값을 수정하기만 하..
[k8s] Namespace, ResourceQuota, LimitRange Namespace 네임스페이스는 쿠버네티스 클러스터 하나를 여러 개의 논리적인 단위로 나누어서 사용하는 것입니다. 네임스페이스 덕분에 쿠버네티스 클러스터 하나를 여러 개 팀이나 사용자가 공유할 수 있습니다. 또한 클러스터 안에서 용도에 따라 실행해야 하는 앱을 구분할 때도 네임스페이스를 사용합니다. 네임스페이스별로 별도의 쿼터를 설정해서 특정 네임스페이스의 사용량을 제한할 수 도 있습니다. 쿠버네티스에서 클러스터 다음으로 분리 단위가 큰 것이 이 네임스페이스이며, 네임스페이스가 가장 먼저 검토해야 할 분리 단위 입니다. 네임스페이스는 여러 개 팀이나, 프로젝트에 많은 사용자가 있는 환경에서 사용하기 적합하며, 사용자가 거의 없거나, 수 십명 정도가 되는 경우에는 네임스페이스를 고려할 필요가 없습니다. 쿠..