스테이트풀셋

필요성

파드별로 각자 다른 persistant volume을 할당하고 싶으면 어떻게 해야 할까. 디플로이먼트의 파드 템플릿은 모두 동일한 pvc를 가지기 때문에 곤란하다.

특정 애플리케이션이 안정적인 네트워크 아이덴티티를 요구(ACL 구성 등)하면 어떻게 해야 할까. 파드 한개당 서비스 한개를 맵핑해야 할까.

스테이트풀셋 이해

이런 유형의 파드를 실행하기 위해 레플리카셋 대신 사용하는것이 스테이트 풀셋 리소스다.

스테이트풀셋은 애플리케이션 인스턴스가 각각 안정적인 이름과 상태를 가지며 개별적으로 취급해야 하는 애플리케이션에 알맞게 만들어졌다.

스테이트풀셋과 레플리카셋

애플리케이션을 애완동물과 가축으로 빗대어

스테이트리스 애플리케이션은 가축이다. 인스턴스가 교체되어도 사용자는 이를 알아차리지 못하고 이용하는데 문제도 없다.

스테이트풀 애플리케이션은 애완동물이다. 애완동물이 죽으면 사용자는 이를 바로 알아차리고 이용하는데 문제가 생긴다. 대체하려는 애완동물을 구할때도 이름과 생김새가 완전히 같은 애완동물을 찾아야 한다. 이에 스테이트풀셋은 초기에 PetSets라고 불렸다.

스테이트풀셋으로 관리되는 파드가 종료되면 새로 교체되는 파드 인스턴스는 이름, 네트워크 아이덴티티, 상태가 동일한 상태로 되살아난다. 각 파드는 다른 피어와 구별되는 자체의 볼륨 세트를 가지며, 예측 가능한 아이덴티티를 가진다.

안정적인 네트워크 아이덴티티

스테이트풀셋 A의 파드는 0부터 시작되는 인덱스가 할당되어 A-0, A-1 과 같이 지어진다.(파드 이름이 컨테이너의 host로 쓰인다.)

거버닝 서비스

스테이트풀 파드는 각각 다르므로 한개를 선택할 때 특정 파드를 선택 할 필요가 있다.

이런 이유로 거버닝 헤드리스 서비스를 생성해서 각 파드에게 실제 네트워크 아이덴티티를 제공해야 한다.

​ ex) default 네임스페이스의 foo라는 거버닝 서비스가 있고 파드의 이름이 A-0이라면,

​ FQDN은 a-0.foo.default.svc.cluster.local로 접근할 수 있다.

이는 레플리카셋으로 관리되는 파드에서는 불가능하다.

또한, foo.default.svc.cluster.local 도메인의 SRV레코드를 조회해서 모든 스테이트풀셋의 파드 이름을 찾는 목적으로도 DNS를 사용 할 수 있다.

스테이트풀셋 스케일링

스테이트풀셋을 스케일업하면 새로운 인스턴스는 다음 서수 인덱스를 갖는다.

​ ex) A-0, A-1 -> A-2

스테이트풀셋을 스케일다운하면 항상 높은 서수의 인덱스를 먼저 제거한다.

​ ex) A-0, A-1 -> A-2

안정적인 스토리지 제공

퍼시스턴트 볼륨과 퍼시스턴트볼륨클레임은 일대일로 맵핑되어 각 파드는 별도의 퍼시스턴트 볼륨을 갖는 각각의 퍼시스턴트볼륨클레임을 참조해야 한다.

볼륨 클레임 템플릿

스테이트풀셋은 파드 템플릿을 구성할 때 각 파드와 함께하는 볼륨 클레임 템플릿을 가질 수 있다.

퍼시스턴트볼륨클레임의 생성과 삭제

스테이트풀셋을 스케일 업하면 두개 이상의 API오브젝트(파드와 파드에서 참조하는 하나 이상의 PVC)가 생성된다. 하지만 스케일 다운을 할때는 파드만 삭제하고 PVC는 남겨둔다.

PVC가 삭제된 후 PV가 재활용되거나 삭제될수 있기 때문이다.

동일 파드의 새 인스턴스에 PVC 다시 붙이기

스케일 다운 이후 스케일 업을 하면 PV에 바인딩된 동일한 PVC를 연결 할 수 있다.

스테이트풀셋이 보장하는 것

스테이트풀셋은 두개의 스테이트풀파드 인스턴스가 절대 동일한 아이덴티티로 실행되지 않고, 동일한 PVC에 바인딩 되지 않도록 보장한다.

만약 파드 교체가 일어나는 경우 새로운 파드를 생성하기 전에 파드가 실행중이 아니라는 것을 확인해야 한다.

디플로이먼트(Deployment)

디플로이먼트는 레플리카 셋 대신 애플리케이션을 배포하고 선언적으로 업데이트 하는 리소스다.

디플로이먼트를 생성하면 레플리카셋 리소스가 생성되고, 레플리카셋 리소스가 파드를 관리한다.

• 디플로이먼트를 만드는 이유

애플리케이션을 업데이트 할 때 추가 레프리카 셋을 만들고 배포를 하는 방식을 통제하여야 하는데, 이를 디플로이먼트가 관리한다.

ex) 낮은 수준의 배포(kubectl을 통한 배포)를 진행하는 중 작업중인 노드가 내려간다면, 배포 중간 상태로 배포가 마무리된다.

디플로이먼트가 레플리카셋을 생성, 레플리카셋이 파드를 생성

디플로이먼트를 작성하며 레플리카셋이 생성한 파드의 이름을 조회하면 <디플로이먼트 이름> + <레플리카셋 해시값> + <파드 해시값> 으로 구성된다.

레플리카셋의 이름은 <디플로이먼트 이름> + <레플리카셋 해시값> 으로 생성되며 이는 레플리카셋이 해당 파드를 관리함을 의미한다.

디플로이먼트가 파드의 템플릿 버전별로 레플리카셋을 생성하기 때문에, 파드 템플릿의 해시값을 사용하면 디플로이먼트에서 지정된 버전의 파드 템플릿에 대하여 항상 동일한 레플리카셋을 사용 할 수 있다.

디플로이먼트 전략

• Rolling Update

  기본 전략. 하나씩 기존 파드를 제거하고 신규 파드로 교체한다.

• Recreate

  모든 기존 파드를 삭제한 뒤 새로운 파드를 만들어 낸다. 서비스 다운타임이 발생한다.

신규 파드 업데이트 이후 레플리카셋이 남아있는 이유

$kubectl get rs 와 같은 명령으로 레플리카셋을 조회해보면 기존에 사용되었던 레플리카셋이 지워지지 않고 남아있다. 디플로이먼트에 의해 관리되는데, 업데이트가 끝난 이후에 왜 계속 남아있을까?

디플로이먼트 롤백

새로 배포된 파드 템플릿에서 오류가 발생한 경우 롤아웃을 되돌려야 한다. 이 때, 디플로이먼트를 사용하여 마지막 혹은 정해진 버전으로 쉽게 롤백할 수 있다. 삭제되지 않은 레플리카셋은 이 때 사용된다.

모든 개정 내역의 수는 디폴로이먼트 리소스의 editionHistoryLimit 속성에 의해 제한된다.(쿠버네티스 버전이 올라가면서 revisionHistoryLimit로 변경)

maxSurge와 maxUnavailable

• maxSurge

  디플로이먼트가 의도하는 레플리카 수보다 얼마나 많은 파드 인스턴스 수를 허용할 것인지. 백분율 혹은 절대값으로 지정. 기본값 25%

• maxUnavailable

  업데이트 중 의도하는 레플리카 수(Desired State) 기준으로 사용할 수 없는 파드 인스턴스 수. 백분율 혹은 절대값으로 지정. 기본값 25%

minReadySeconds

일정시간동안 준비상태를 검사하여 rollout하는 디플로이먼트 spec의 리소스 속성이다.

오작동 버전의 배포를 방지할 수 있다.

사용 가능한 파드가 되려면 minReadySeconds 기간동안 readiness probe가 성공해야 한다.

롤아웃 데드라인

기본적으로 10분동안 롤아웃이 진행되지 않으면 실패한것으로 간주된다.

디플로이먼트의 ProgressDeadlineExceeded 으로 확인 할 수 있다.

디플로이먼트 스펙의 progressDeadlineSeconds 속성으로 정의 할 수 있다.

서비스

세션 어피니티

동일한 명령을 실행하더라도 서비스 프록시가 각 연결을 임의의 파드로 전달하기 때문에 연결 할 때 마다 임의의 파드가 선택된다.

반면 특정 클라이언트의 모든 요청을 매번 같은 파드로 전달하려면 서비스의 세션 어피니티 속성을 기본값 None 대신 ClientIP로 설정해야 한다.

apiVersion: v1
kind: Service
spec:
    sessionAffinity: ClientIP
...

DNS를 통한 서비스 검색

• 클러스터에서 실행중인 다른 모든 팟이 사용하는 kube-dns 라는 시스템 리소스가 있다.
• kube-dns는 모든 서비스를 알고있는 쿠버네티스의 자체 DNS 서버.
• 파드가 내부 DNS 서버를 사용할 지 여부는 각 파드 스펙의 dnsPolicy 속성으로 구성 할 수 있다.
• 서비스 이름을 알고 있는 파드는 FQDN(Fully Quallified Domain Name)으로 통신 할 수 있다.위 curl은 클러스터 내부의 pod을 kubectl exec 명령을 통해 실행한 상태에서 수행한다. (클러스터 내부 통신이기 때문)
  • svc.cluster.local 은 모든 클러스터의 로컬 서비스 이름에 사용되는 클러스터의 도메인 접미사. 생략 가능하다.
  • 파드가 같은 네임스페이스에 있는 경우 네임스페이스도 생략할 수 있다. 단순히 서비스의 이름만 써도 된다.
  • 파드 컨테이너 내부의 DNS resolver 구성 /etc/resolv.conf 를 보면 이해 할 수 있다.
• Ex) curl http://svc-orra-dev.ns-ordev.svc.cluster.local:8082
• 서비스에 IP 핑은 할 수 없다.

외부 클라이언트에 서비스 노출

• 노드포트로 서비스 유형(Type) 설정
• 서비스 유형을 노드포트 유형의 확장인 '로드밸런서'로 설정
• 단일 IP 주소로 여러 서비스를 노출하는 인그레스 리소스 만들기

노드포트

노드포트 타입 서비스를 만들면, k8s는 모든 노드에 특정 포트를 할당하고 서비스를 구성하는 파드로 들어오는 요청을 전달한다.

로드밸런서

로드밸런서 타입 서비스를 만들면, 일번적으로 클라우드 인프라에서 로드밸런서를 자동으로 프로비저닝하는 기능을 제공한다. 쿠버네티스가 로드밸런서 서비스를 지원하지 않는 환경에서 실행중인 경우 노드포트 서비스처럼 작동한다.

서비스를 생성하고 클라우드 인프라가 로드밸런서를 생성하고 IP주소를 서비스 오브젝트에 쓰면, 로드밸런서 IP주소가 서비스의 external IP 주소로 표시돤다.

외부 연결 특성의 이해

불필요한 홉

외부에서 노드포트로 서비스에 접속하는 경우, 서비스가 임의로 선택한 파드가 동일 노드일 수도 있고, 아닐수도 있다. 파드에 도달하려면 추가 네트워크 홉이 필요한 경우가 생길 수 있다.

외부 연결을 수신한 노드에서 실행중인 파드로만 외부 트래픽을 전달하도록 서비스를 구성할 수 있다. 서비의 스펙에 externalTrafficPolicy 필드를 설정하면 된다.

spec:
    externalTrafficPolicy: Local

하지만 로컬에 파드가 없으면 연결이 중단되어버린다. (Kubernetes 1.15 이상: 패킷이 다른 노드에 있는 구성원 pod로 전달)

클라이언트 IP가 보존되지 않음

클러스터 내 클라이언트가 서비스로 연결 할 때, 서비스의 파드는 클라이언트의 IP주소를 얻을 수 있다.

하지만 노드포트로 연결을 수신하면 패킷에서 소스 네트워크 주소 변환(source network address translation)이 수행되어 소스 IP가 변경된다.

예를들어 엑세스 로그에 브라우저 IP를 남길 수 없는 문제가 생길 수 있다.

하지만 externalTrafficPolicy를 설정 한 경우, 노드 사이에 추가 홉이 없기 때문에 SNAT이 수행되지 않는다.

인그레스

필요성

로드밸런서 서비스는 공용 IP주소를 가진 로드밸런서가 필요하지만, 인그레스는 한 IP주소로 수십개의 서비스에 접근이 가능하도록 지원해준다.

클라이언트가 http 요청을 인그레스에 보낼 때, 요청한 호스트와 경로에 따라 요청을 전달할 서비스를 결정한다.

인그레스는 L7에서 동작하며, 쿠키 기반 세션 어피니티 등과 같은 기능을 제공 할 수 있다.

레디니스 프로브(Readiness Probe)

주기적으로 호출되며 특정 파드가 클라이언트의 요청을 수신 할 수 있는 상태인지 결정한다.

Exec Probe

프로세스를 실행시켜 종료 상태 코드로 결정한다.

Http Get Probe

http get 요청을 보내 http 응답 상태 코드를 보고 준비 여부를 결정한다.

TCP Socket Probe

지정된 포트로 TCP 연결을 수행하여 소켓이 연결되면 준비된것으로 간주한다.

레디니스 프로브 동작

컨테이너가 시작 될 때 첫번째 점검을 수행하기 전 기다리는 시간을 구성할 수 있다.(initialDelaySeconds)

그 다음 주기적으로 레디니스 프로브를 수행한다. 파드가 준비 상태가 되지 않으면 서비스의 엔드포인트에서 제거된다. 준비되면 다시 서비스에 추가된다.

Liveness Probe와 다르게 준비 상태가 아니더라도 컨테이너가 재시작 되지 않는다.

레디니스 프로브 중요성

만약 프론트엔드 파드중 하나에 연결 문제가 발생해 더 이상 DB에 연결 할 수 없는 경우, 레디니스 프로브를 통해 쿠버네티스에 알려야 한다.

레디니스 프로브를 항상 정의해야 하는 이유

파드에 레디니스 프로브를 추가하지 않으면, 파드가 시작하는 즉시 서비스의 엔드포인트가 된다.

애플리케이션을 시작하는데 오래 걸리는 경우, 준비가 되지 않은 파드로 요청이 전달되어 "Connection refused"와 같은 에러를 보게 된다.

레디니스 프로브에 파드의 종료 코드를 포함하지 말아야 한다

쿠버네티스는 파드를 삭제하자마자 모든 서비스에서 파드를 제거하기 때문에, 레디니스 프로브에 파드의 종료 코드를 포함할 필요가 없다.

헤드리스 서비스

쿠버네티스가 서비스에 대한 DNS 조회를 수행하면 DNS 서버는 서비스의 클러스터 IP를 반환한다.

하지만 서비스 스펙에서 clusterIP 필드를 None으로 설정하면 서비스 IP 대신 파드 IP들을 반환한다.

이를 이용해 클라이언트는 하나 이상의 파드에 연결 할 수 있다.

이는 READY 상태가 된 파드만 보여주며 준비되지 않은 파드도 포함하려는 경우 서비스에 다음과같이 어노테이션을 추가해야 한다.

kind: Service
metadata:
    annotations:
        publishNotReadyAddresses: "true"

서비스 트러블슈팅

• 외부가 아닌 클러스터 내에서 서비스 클러스터 IP에 연결되는지 확인한다.
• 서비스에 액세스 할 수 있는지 확인할 때, 클러스터 IP에 핑을 때리는건 의미없다.(서비스의 클러스터 IP는 가상 IP임으로 핑에 응답하지 않음.)
• Readiness Probe를 정의했다면 확인한다. publishNotReadyAddresses 어노테이션이 없다면 준비되지 않은 파드는 서비스에 포함되지 않는다.
• 파드가 서비스에 포함되어있는지 확인하려면 'kubectl get endpoints'를 조회해 확인한다.
• FQDN이나 그 일부로 서비스에 접근하는 경우, FQDN 대신 클러스터 IP로 접근해본다.
• 대상 포트(target port)가 아닌 서비스의 포트로 연결되는지 확인한다.
• 파드 IP에 직접 연결해 파드가 올바른 포트에 연결되어 있는지 확인한다.
• 파드 IP로 접근할 수 없는 경우, 애플리케이션이 localhost에만 바인딩하는지 확인한다.

POD을 안정적으로 유지하기

컨테이너에 주 프로세스에 크래시가 발생하면 kubelet이 컨테이너를 재시작한다.

하지만 크래시 없이 애플리케이션이 중단되는 경우(ex. 자바 애플리케이션의 메모리누수로 OutofMemorysErrors가 발생해도 JVM 프로세스는 중단되지 않는다.)에, 쿠버네티스에 신호를 보내 애플리케이션을 재시작하도록 하는 방법이 있어야 한다.

Liveness Probe

각 컨테이너가 정상인지 확인한다. 프로브가 실패하는 경우, 컨테이너를 재시작한다.

spec에 지정 할 수 있다.

• HTTP Get

  지정한 IP주소, 포트, 경로에 HTTP Get 요청을 수행한다.

  응답 코드가 4xx, 5xx와 같은 오류가 아니라 2xx, 3xx인 경우 성공.

  http 오류 코드 혹은 응답이 없는경우 실패.

• Socket

  지정된 포트에 TCP 연결을 시도한다. 연결의 성공여부가 프로브의 성공여부.

• Exec

  컨테이너 내의 임의의 명령을 실행하고 종료 코드를 확인한다.

  상태코드가 0이면 성공, 다른 모든 코드는 실패.

*크래시된 컨테이너의 로그 얻기

컨테이너가 재시작되면 kubectl logs 명령은 현재 컨테이너의 로그를 표시한다.

이전 컨테이너의 로그를 얻고 싶다면 --previous 옵션을 사용한다.

$ kubectl logs [POD] --previous

Liveness Probe 추가설정

delay

컨테이너가 시작된 후 일정시간 뒤에 liveness probe 실행 (ex. delay=0s)

timeout

컨테이너가 응답해야 하는 제한시간. 제한시간 내 응답 못할시 실패. (ex. timeout=1s)

period

liveness probe 실행주기. (ex. period=10s)

failure

몇 번 연속 실패하면 컨테이너가 다시 시작되는지에 대한 값. (ex. failure=3)

쿠버네티스를 구축하는 방법은 다양하다.

가장 쉬운 방법은 AWS EKS(Elastic Kubernetes Service), GCP GKE(Google Kubernetes Engine), 국산을 좋아한다면 NCP의 Kubernetes Sercie를 이용하는 방법이 있다.

쿠버네티스에서 제공하는 Cloud volume 마운트 기능 등을 각 플랫폼에서 제공하는 방법으로 쉽게 쉽게 Mount를 할 수도 있고 레퍼런스도 많고 무수한 장점이 있겠지만 지속적으로 비용이 발생한다는 단 하나의 단점이 있다.

그래서 방구석에서 쿠버네티스 클러스터를 구축해보며 까먹지 않기 위해 기록한다.

OS

- Ubuntu 18.04.5 LTS

Container Runtime

- Docker

컨테이너는 CRI-O 등 대안이 존재하지만 워낙 레퍼런스 찾기가 힘들어 사실상의 표준이라 생각하는 도커를 사용했다.

클러스터 구축 툴

- kubeadm

오픈소스 프로젝트라 그런지 구축을 결심하자마자 선택지부터 발생했다.

쿠버네티스 클러스터 구축을 도와주는 toolkit으로는 kubeadm, kops, kubespray등의 도구가 있다.

kubeadm을 선택한 이유는 가장 레퍼런스가 많아서.. 이므로 각 툴의 원하는 기능이 있다면 다른 도구를 사용해 구축하는게 편할 것이다.

1. Update

$ apt update -y
$ apt upgrade -y

모든 노드의 패키지를 업데이트받는다.

2. Swap Memory off

$ sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab
$ swapoff -a

쿠버네티스 환경에서는 Swap기능을 off하는게 권장된다.

관련 discussion이 있으니 나중에 확인.

3. Docker 설치

$ sudo apt-get update && sudo apt-get install -y
$ apt-transport-https ca-certificates curl software-properties-common gnupg2
$ curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key --keyring /etc/apt/trusted.gpg.d/docker.gpg add -
$ add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
$ apt update

여기까지 진행 한 후 만약 apt install -y containerd.io docker-ce 같은 명령어로 도커를 설치하지 말고 쿠버네티스 버전과 도커 버전을 잘 확인 후 진행하도록 하자..

해당 정보는 여기에서 확인 할 수 있다.

나의 쿠버네티스는 v1.20.2이며 도커는 19.03.12 버전을 설치했다.

$ apt-cache madison docker-ce

위 명령어로 버전을 확인 한 후

$ sudo apt-get install docker-ce=5:19.03.12~3-0~ubuntu-bionic docker-ce-cli=5:19.03.12~3-0~ubuntu-bionic containerd.io

명령으로 도커를 설치했다.

$ mkdir -p /etc/systemd/system/docker.service.d
$ tee /etc/docker/daemon.json < {\
"exec-opts": ["native.cgroupdriver=systemd"],\
"log-driver": "json-file",\
"log-opts": {\
"max-size": "100m"\
},\
"storage-driver": "overlay2"\
}
EOF

이후 directory와 configuration을 만들어주고 도커를 재시작한다.

$ systemctl daemon-reload
$ systemctl restart docker
$ systemctl enable docker

kubelet, kubeadm, kubectl을 설치한다.

$ apt-get update
$ apt-get install -y
$ apt-transport-https curl
$ curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add -
$ echo "deb https://apt.kubernetes.io/ kubernetes-xenial main" | tee /etc/apt/sources.list.d/kubernetes.list
$ apt update
$ apt -y install vim git curl wget kubelet kubeadm kubectl
$ apt-mark hold kubelet kubeadm kubectl

방화벽 설정 (패킷 포워딩 활성화)

$ modprobe overlay
$ modprobe br_netfilter
$ tee /etc/sysctl.d/kubernetes.conf< net.bridge.bridge-nf-call-ip6tables = 1\
net.bridge.bridge-nf-call-iptables = 1\
net.ipv4.ip_forward = 1\
EOF
$ sysctl --system

Kubelet 시작, kubeadm 이미지 업데이트, kubeadm 으로 클러스터 시작

$ systemctl enable kubelet
$ kubeadm config images pull
$ kubeadm init --pod-network-cidr=10.244.0.0/16

클러스터의 pot network 옵션을 위와 같이 지정한건 이후 CNI로 flannel을 사용할 예정이기 때문이다.

flannel은 위와 같이 pod network 옵션을 주는 것을 권장하고 있다.

다른 CNI를 사용한다면 해당 CNI에서 권항하는 ip대역대가 있는지 한번 알아보면 좋을 것 같다.

calico에서는 pot-network 대역으로 192.168.0.0/16 를 권장한다.

kubeadm init을 한다면 

kubeadm join master:6443 --token ~~ \
--discovery-token-ca-cert-hash sha256:~~~

이러한 형태의 토큰을 확인 할 수 있는데, 다른 노드에서 해당 토큰으로 쿠버네티스 클러스터에 접근 할 수 있다.

만약 까먹거나 24시간이 지났다면

$ kubeadm token list
$ openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | openssl dgst -sha256 -hex | sed 's/^.* //'

다시 확인 할 수 있다.

$ mkdir -p $HOME/.kube
$ cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
$ chown $(id -u):$(id -g) $HOME/.kube/config

위 명령어 3종세트로 kubectl에 대한 권한을 해당 계정에 부여 할 수 있다.

coredns loop 해제

$ kubectl edit cm coredns -n kube-system

위 명령어로 실행하여 loop 옵션을 주석처리한다.

CNI설치

falnnel

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml 

calico

kubectl create -f https://docs.projectcalico.org/manifests/tigera-operator.yaml

guide: https://docs.projectcalico.org/getting-started/kubernetes/quickstart

참고자료

www.liquidweb.com/kb/how-to-install-kubernetes-using-kubeadm-on-ubuntu-18/