By oneself

아무리 k8s를 잘 사용해서 pod를 띄우고 서비스를 연결하고, 인증을 시크릿으로 올려 마운트 시키고 등등 하여도 외부에 오픈을 해야 쓸모있는 시스템이 된다. 이렇게 외부에서 접근을 할 수 있도록 관리해주는 오브젝트가 인그레스이다.

아래 이미지는 쿠버네티스 공식 도큐먼트에 나와있는 그림이다.

인그레스 컨트롤러가 동반이 되어야 실제 rule을 적용시키고 트래픽을 받을 수 있으며, 인그레스 컨트롤러의 종류는 공식 홈페이지에서 찾아볼 수 있다.

https://kubernetes.io/ko/docs/concepts/services-networking/ingress-controllers/

살펴보면 AWS,GCE,nginx를 지원하고, 이 외에도 F5 BIG-IP, Citrix등 굉장히 많은 것들을 지원한다. 

한번 어떤방식으로 작동하는지 살펴보기 위해 nginx를 볼 예정이다. 

아래 사이트를 접속하면 내 k8s 환경에 따라 여러가지 방법들을 제시한다.

https://kubernetes.github.io/ingress-nginx/deploy/

자신의 상황에 맞는 Contents를 선택하여 시작해보자. 글쓴이는 GCP의 일반 VM을 사용하기에 Bare-metal을 살펴보겠다.

접속한후 kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.3.1/deploy/static/provider/baremetal/deploy.yaml 부분에서 https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-v1.3.1/deploy/static/provider/baremetal/deploy.yaml  를 웹에서 접속해보면 Yaml을 볼 수 있다.

살펴보면 Role, ServiceAccount 등 여러가지 오브젝트들을 확인할 수 있고, 중간에 보면 아래와 같이 Service가 있는 것을 볼 수 있다.

apiVersion: v1
kind: Service
metadata:
  labels:
    app.kubernetes.io/component: controller
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
    app.kubernetes.io/version: 1.3.1
  name: ingress-nginx-controller
  namespace: ingress-nginx
spec:
  ipFamilies:
  - IPv4
  ipFamilyPolicy: SingleStack
  ports:
  - appProtocol: http
    name: http
    port: 80
    protocol: TCP
    targetPort: http
  - appProtocol: https
    name: https
    port: 443
    protocol: TCP
    targetPort: https
  selector:
    app.kubernetes.io/component: controller
    app.kubernetes.io/instance: ingress-nginx
    app.kubernetes.io/name: ingress-nginx
  type: NodePort

이것이 이제 컨트롤러 pod이며 노드포트 타입으로 열려있고 80, 443 port로 들어오는 트래픽을 앞단에서 받아주는 것을 볼 수 있다. 이것이 맨위 인그레스 이미지에서 client다음에 있는 부분이라고 볼 수 있다. 이후 backend서버와 연결하는 부분이 필요한데, 이 부분은 아래 따배런 강사님의 유튜브를 보며 해당 백엔트 서버 코드를 참고했다.

https://www.youtube.com/watch?v=9TMIetXb6Pw 

해당 영상을 보고 marvel과 payment를 배포했다고 가정하고 ingress를 배포해 보자.

아래처럼 path별로 어떤 서비스와 연결할 것인지 명시하는 부분이 있다. 그리고 ingress를 배포한 후 아까 ingress-controller를 배포한 nodeport로 curl을 날려보자

curl workerIP:nodePort로 하면 /로 연결이 되기 때문에 marvel-service로 연결이 된다.

아래와 같이 잘 뜨는 것을 볼 수 있다.

curl workerIP:nodePort/pay라고 하면 ingress에 명시되어 있는 pay-service로 연결이 된다.

이처럼 ingress에서는 L7로드밸런서와 비슷하게 외부에서 접속을 할 수 있도록 도와준다.

AWS를 사용하는 경우는 아래 글을 읽어보면 좋을것 같다.

https://aws.amazon.com/ko/blogs/opensource/kubernetes-ingress-aws-alb-ingress-controller/

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

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

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

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

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