Framework and Tool/Kubernetes17 Kubernetes - Persistent storage - 출처: Kubernetes in action - 퍼시스턴트 스토리지 파드에서 실행중인 앱이 Disk에 데이터를 유지해야 하거나 파드가 다른 노드로 재 스케줄링 된 경우에도 동일한 데이터를 사용해야 한다면 NAS(network-attached-storage) 유형에 저장돼야 한다. MongoDB를 Persistent disk에 연동하는 예제를 살펴보자. minikube 환경이기 때문에 hostPath로 흉내내본다. apiVersion: v1 kind: Pod metadata: name: mongodb spec: containers: - image: mongo name: mongodb volumeMounts: - name: mongodb-data mountPath: /data/db ports: - con.. 2022. 11. 12. Kubernetes - Volume - 출처: Kubernetes in action - 볼륨 소개 볼륨은 파드의 구성요소이며, 파드의 spec 에서 정의한다. 독립적인 쿠버네티스의 구성요소는 아니어서 자체적으로 생성이나 삭제가 불가능하다. 파드의 모든 컨테이너에서 사용가능하지만 접근하려는 컨테이너에서 마운트 돼야한다. 예를 들어 아래와 같은 컨테이너들이 있다고 가정해보자. 웹서버: /var/htdocs 디렉터리에서 HTML 페이지 서비스, /var/logs 에 엑세스 로그를 저장하는 웹서버 실행 컨텐츠 에이전트: /var/html 에 html 을 생성하는 에이전트 로그 로테이터: /var/logs 디렉터리를 처리(로그 순환, 압축, 분석) 또한 아래 2 가지 볼륨을 갖는다고 가정하자. 볼륨1: HTML 공유 볼륨 볼륨2: 로그 공유 볼륨 .. 2022. 11. 12. Kubernetes - readness probe, headless service - 출처: Kubernetes in action - 레디니스 프로브 서비스의 레이블 셀렉터와 파드의 레이블이 일치하면 해당 파드는 서비스 관리대상(엔드포인트 리소스에서 IP 목록으로 유지함)이 된다. 요청이 서비스로 전송된 후에 서비스는 임의의 파드로 해당 요청을 전송하는데 만약 파드가 요청을 처리할 준비가 되지 않은 상황이라면 어떻게 해야 할까? 앞서 이와 비슷한 라이브니스 프로브를 알아본적이 있다. 라이브니스 프로브는 불안전한 컨테이너를 다시 시작해서 앱의 상태를 원활하게 유지한다. 레디니스 프로브도 주기적으로 호출되며 특정 파드가 클라이언트 요청을 수신할 수 있는지 여부를 판단한다. 이때 준비가됐다는 기준은 앱의 특성에 맞도록 개발자가 잘 정의해야 한다. 레디니스 프로브에도 3 가지 유형이 존재한다.. 2022. 10. 30. Kubernetes - ingress - 출처: Kubernetes in action - 인그레스 리소스 인그레스(ingress)란 들어가거나 들어가는 행위, 들어갈 수단, 장소, 진입로라는 의미를 갖고 있다. 인그레스 리소스를 사용하면 외부로 서비스를 노출할 수 있다. 이미 외부에 서비스를 노출하기 위한 유형으로 노드포트와 그의 확장형인 로드 밸런서를 살펴보았다. 그렇다면 인그레스라는 리소스는 왜 필요할까? 로드 밸런서는 자신의 공용 IP를 가진 로드 밸런서가 필요하다. 반면 인그레스는 한 IP 주소로 수십개의 서비스에 접근이 가능하다. 또한 네트워크 스택의 애플리케이션 계층(HTTP)에서 작동 하므로 서비스가 할 수 없는 쿠키기반 세션 어피니티와 같은 기능을 제공할 수 있다. 인그레스 리소스를 사용하려면 클러스터에 인그레스 컨트롤러를 실.. 2022. 10. 30. Kubernetes - External service, Service export - 출처: Kubernetes in action - 클러스터 외부에 있는 서비스 연결 지금까지는 모두 클러스터 내부의 파드에 대해서만 통신을 지원하는 서비스를 설명했다. 하지만 쿠버네티스는 외부 서비스를 노출해서 외부 IP과 포트로 연결을 전달할 수 있다. 즉 클러스터 내부 클라이언트 파드에서 외부 서비스로 연결이 가능하다. - 서비스 엔드포인트 서비스와 파드 연결 과정에는 숨은 리소스가 있다. 서비스는 파드에 직접 연결되는것이 아니라 서비스 - 엔드포인트 리소스 - 파드로 연결된다. "kubectl describe svc"명령어로 서비스 정보를 확인해보자. 항목을 보다보면 엔드포인트(Endpoints)란 속성을 확인할 수 있을것이다. 엔드포인트 리소스는 서비스로 노출되는 파드의 IP와 포트 목록이다. .. 2022. 10. 24. Kubernetes - Service intro - 출처: Kubernetes in action - 서비스 시스템을 마이크로 서비스로 구성하기로 했다면 파드가 통신하는 유형은 대게 아래 2가지 경우에 해당할것이다. 클러스터 내부의 다른 파드에서 오는 HTTP 요청에 응답 클러스터 외부 클라이언트에서 오는 HTTP 요청에 응답 만약 쿠버네티스를 사용하지 않는 상황에서 다른 서비스를 이용할때 보통은 환경설정 파일에 IP나 Host 이름을 설정하는 방식으로 사용한다. 하지만 쿠버네티스는 이런 방식으로 사용할 수 없는데 그 이유는 아래와 같다. 파드는 일시적이다. IP 주소 할당 시점이 노드에 파드를 스케줄링한 후 파드가 시작되기 바로 전이라 미리 알수 없다. 쿠버네티스는 수평 스케일링을 제공한다. 이 의미는 파드수와 IP에 상관없이 여러 파드가 동일한 서비.. 2022. 10. 21. Kubernetes - job and cron job - 출처: Kubernetes in action - 잡 리소스 레플리케이션 컨트롤러, 레플리카셋, 데몬셋은 지속적인 Task를 실행하므로 이런 종류로 생성한 리소스들의 파드들은 프로세스가 종료되면 다시 시작된다. 하지만 완료 가능한 Task 같이 프로세스 종료 후 재시작 하지 않는 유형도 고려해볼 수 있다. 쿠버네티스에서는 잡 리소스라는것으로 이런 작업 유형을 지원한다. 잡은 파드 내부의 컨테이너에서 실행중인 프로세스가 성공적으로 완료했다고 판단되면 컨테이너를 다시 시작하지 않는 파드를 실행핸다. 노드에 장애가 발생하면 잡이 관리하는 파드는 레플리카셋 파드와 동일하게 다른 노드로 스케줄링 된다. 만약 프로세스 자체적으로 장애가 있다면 설정에 따라 재시작할 것인지를 설정할 수 있다. 잡 리소스의 예로는 데.. 2022. 10. 21. Kubernetes - ReplicaSet, DaemonSet - 출처: Kubernetes in action - 레플리카 셋 초기에는 레플리케이션 컨트롤러(이하 "rc") 만이 파드를 복제하고 노드에 장애가 발생하면 재 스케줄링 하는 유일한 쿠버네티스 구성요소였다. 이후 등장한 레플리카 셋은 차세대 구성요소이며, rc는 사장될 예정이다. 현재 쿠버네티스 rc 문서(https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller/) 에서도 레플리케이션을 세팅할 때는 디플로이먼트를 사용할것을 권고하고 있다. rc와 레플리카셋은 거의 동일해서 하나만 알면 다른 하나를 사용하는데 무리가 없다. 일반적으로 레플리카셋 리소스를 직접 생성 하지는 않으며 상위 수준의 디플로이먼트 리소스를 이용한다. .. 2022. 10. 14. Kubernetes - Replication controller - 출처: Kubernetes in action - 레플리케이션 컨트롤러 레플리케이션 컨트롤러(이하 "rc")는 쿠버네티스 리소스이며 파드가 항상 실행되도록 보장해준다. 어떤 워커노드가 다운 되거나 워커 노드 내에서 파드가 사라지면 감지해서 교체 파드를 생성한다. 직접 생성한 파드 A와 rc에 의해 생성된 파드 B가 같은 워커 노드에 있을 때 노드가 다운 된다면 파드 A는 유실되지만 파드 B는 rc에 의해 관리되기 때문에 새로 생성된다. - rc의 동작 rc는 실행중인 파드 목록을 모니터링해서 "특정" 유형의 파드수가 설정한 파드 수와 일치하는지를 확인한다. 모니터링해서 파드 수가 모자라면 신규 파드를 생성하며 파드가 많아지면 제거한다. 파드수가 모자라는 상황은 이해가 가는데 어떻게 파드가 많아질 수 있.. 2022. 10. 11. Kubernetes - Liveness probe - 출처: Kubernetes in action - 파드 유지 쿠버네티스의 최대 장점은 컨테이너 목록을 제공하면 관리자가 신경쓰지 않아도 클러스터 어딘가에서 계속 실행되고 있다고 믿을 수 있다는것이다. 파드가 워커 노드에 스케줄링되면 노드의 kubelet은 컨테이너를 실행한다. 이때 주 프로세스에 crash가 발생하면 kubelet은 컨테이너를 재시작한다. 하지만 문제는 앱이 쓸 수 없게 되는 상황에서 언제나 crash가 발생하지는 않는다는것이다. 예를 들어 자바 앱에서 메무리 누수가 일어나는 경우 OOM이 일어날지언정 JVM 프로세스는 계속 실행된다. 이럴 경우 OOM 익셉션을 잡아서 재시작하면 되겠지만 이런식으로 모든 경우의 수를 대비할수는 없다. 그러므로 앱 내부 기능이 아닌 외부에서 앱의 상태를 .. 2022. 10. 10. 이전 1 2 다음
