By oneself

스테이트풀셋은 애플리케이션의 스테이트를 관리하는데 사용하는  오브젝트이다. 파드들의 순서 및 고유성을 보장한다 .

디플로이먼트와 유사하게, 스테이트풀셋은 동일한 컨테이너 스펙을 기반으로 둔 파드들을 관리한다

디플로이먼트와는 다르게, 스테이트풀셋은 각 파드의 연결 등 각종 연결된 정보상태를 유지한다. 

디플로이먼트를 생성하면 아래 그림과 같이 생성이 된다.

pod의 이름에는 랜덤한 난수값이 붙고 PVC에 붙게 된다.

이 상황에서 pod한개를 delete하면 새로 다른 이름의 pod를 create하고 pvc에 연결한다.

하지만 statefulset은 아래와 같은 이미지와 같이 리소스가 생성된다.

각 pod마다 고유한 PVC가 생성이 되고, pod와 pvc의 이름도 난수값이 아닌 고유한 식별자가 붙게 된다.  또한 pod를 delete하면 다른 이름의 pod로 create 되는 것이 아니라 같은 이름의 pod가 다시 create되며 같은 pvc도 붙게 된다.

스테이트 풀셋은 기본적으로 데이터를 분실하지 않도록 설계되어있다. 하지만 장애로인해 특정 노드가 정지되어 사용불가가 되었을때 스테이트풀셋은 새로운 pod를 기동하지 않는다. 상태를 보존하기 위해서다. 

정지가 아니라 k8s에서 node를 삭제하면 다른 노드에서 기동된다.

사실 현업에서 이러한 방법을 운영환경에서 잘 사용하는지 모르겠다.

어떤 시스템이든 스토리지는 굉장히 중요하다. 어플리케이션이 작동하기 위해, 또는 작동하면서 생성한 다양한 것들을 어딘가 저장하고 읽어야 한다.

쿠버네티스에서도 여러가지 방법들이 있다.

먼저 노드 내부에서 간단하게 사용할 수 있는 볼륨은 emptyDir, hostPath가 있다.

emptyDir는 pod안에서 접근할 수 있다, pod내부에서 사용할 수 있도록 설계되어 있다. 

이말은 pod가 삭제되면 같이 휘발된다는 말이다.

아래 yaml은 한 pod안에 2개의 컨테이너가 있고 2번째 컨테이너가 date를 index.html로 저장한다. 이렇게 저장된 정보를 

1번째 컨테이너에서 읽어보자. 

즉 아래와 같은 그림이다.

해당 pod를 describe 해보면 2개의 컨테이너가 있는 것을 볼 수 있다.

이제 첫번째 컨테이너에 접속해서 두번째 컨테이너가 생성한 date정보를 보자. 

아래 명령어를 통해 특정 컨테이너에 접속하자.

이후 /usr/share/nginx/html에 접속한 후 index.html를 보자.

아래와 같이 두번째에서 찍은 정보를 확인할 수 있다.

이제 pod를 삭제하면 모든 데이터가 같이 삭제된다.

하지만 pod가 삭제되어도 정보가 사라지지 않았으면 한다. 이번에는 노드의 볼륨을 사용하는 hostpath를 해보자.

아래 yaml을 통해 hostpath pod를 실행해보자.

이후 생성된 pod를 확인하고 접속한 후 /etc/data밑에 hello파일을 생성해보자.

해당 pod가 기동된 node를 확인후 해당 node에서 /tmp를 확인해보면 아래와 같이 hello파일이 있는 것을 볼 수 있다.

이제 pod를 삭제해도 해당 파일은 보존이 된다.

하지만 쿠버네티스는 auto healing기능이 있다. 그만큼 pod가 죽어도 상관없이 새로 기동되는 성질을 장점으로 가지고 있는데, 이렇게 특정 node에 종속되는 볼륨은 개인적으로 운영에서는 좋지 않다고 생각을 한다. 그럼 다른 방법을 생각해보자.

쿠버네티스에서는 퍼시스턴트볼륨이라는 것을 제공한다.

아래과 같은 그림이다.

퍼시스턴트 볼륨

퍼시스턴트볼륨은 관리자가 프로비저닝하거나 스토리지 클래스를 사용하여 동적으로 프로비저닝한 클러스터의 스토리지이다.

PV는 클러스터 리소스이다. PV는 Volumes와 같은 볼륨 플러그인이지만, PV를 사용하는 각각의 파드와는 다른 라이프사이클을 가진다. 이 API 오브젝트는 NFS, iSCSI 또는 클라우드 공급자별 스토리지 시스템 등 스토리지 구현에 대한 세부 정보를 담아낸다.

지원가능한 스토리지 종류들에 대해서는 공홈에 나와있는 것처럼 아래 이미지와 같다. 또한 접근 정책에 대해서도 나와있다.

아래 그림을 보며 pod, pvc,pv의 관계를 보자.

pod를 생성할때 볼륨 마운트 부분에서  path등을 명시하고, 볼륨에서는 PVC에 대해 명시해 준다.

이렇게 생성하면 해당 PVC가 PV를 찾아 연결해준다. 

AWS와 같은 클라우드를 사용하면 EBS, EFS 등을 통해 노드에서 같은 소스로 접근이 가능하다. 

PVC를 이용해 동적으로 PV를 사용하고 싶다면 스토리 클래스를 활용하면 된다. 사용자 환경에 맞게 프로비저너를 넣어주면 된다.

위 그림에서 하나 주목할 부분은 PVC는 네임스페이스 영역에 들어갈 수 있으며, PV는 공용으로 사용되기에 네임스페이스 영역에서 빠져있다.

AWS의 사례를 보면 스토리지에 대한 이해를 더 쉽게 할 수 있다.

아래 블로그를 참고해보자.

https://cloud.netapp.com/blog/aws-cvo-blg-aws-ebs-multi-attach-volumes-and-cloud-volumes-ontap-iscsihttps://towardsdatascience.com/stop-duplicating-deep-learning-training-datasets-with-amazon-ebs-multi-attach-d9f61fdc1de4

크론잡

크론잡은 반복 일정에 따라 잡을 생성한다. 리눅스의 cronjob과 같은 역할을 한다고 볼 수 있다.

배치성 작접과 같이 무언가를 반복해서 실행해야 하는 경우에 사용하면 된다.

스케쥴 문법은 공홈에서 제공하는 정보를 보고 이해하자.

아래와 같이 yaml을 작성하고 스크립트가 있다면 스크립트를 실행하도록 command에 추가해 주면 된다.

사실 개인적으로는 괜찮은 ui와 각종 플러그인을 제공하고 실패 유무를 로그와 함께 제공하는 jenkins를 사용하는 것을 훨씬 선호한다.