Kubernetes Study를 하며...

• Container

POD안에 하나의 독립적인 서비스를 구성 할 수 있는 Container가 있다. 그 컨테이너들은 서비스가 연결될 수 있도록 포트를 가지고 있는데, 한 컨테이너가 포트를 하나 이상 가질 수는 있지만 한 POD 내에서 컨테이너들 끼리 포트가 중복 될 수는 없다. pod가 생성될 때 고유의 ip주소가 할당이 되는데 쿠버네티스 클러스터안에서만 이 ip를 통해서만 pod로 접근 할 수 있다. pod에 문제가 있으면 시스템에서 감지를 하고, 이 pod를 삭제하고 재생성하게 되는데 이 ip 주소는 새로 할당 된다. 휘발성 있는 ip 주소.

• Label

라벨은 pod뿐만이아니라 모든 object에 달 수 있는데 목적에 따라 object들을 분류하고, 분류된 object들만 따로 골라서 분류하기 위해. 라벨의 구성은 key, valuer가 한쌍이고, 한 pod에는 여러개의 라벨을 달 수가 있다. 라벨을 dev, production으로 달게되면 개발과 운영환경을 나눌 수 있다. 사용 목적에 따라 라벨을 등록하면, 해시태그처럼 원하는 pod를 골라서 사용 할 수 있다.

• Node Schedule

pod는 결국 여러 node들 중에 한 node에 올라가야한다. 직접 Node를 선택하는방법, 쿠버네티스가 자동으로 지정해주는 방법이 있다. pod에 라벨을 다는 것 처럼 node에 라벨을 달고 pod를 만들 때 node를 지정 할 수 있다. pod에서 사용될 리소스의 사용량을 명시 할 수 있는데, 각 Node의 사용량을 보고 적절한 Node를 지정을 해준다.

• Service

서비스는 기본적으로 자신의 Cluster IP를 가지고 있다. 서비스의 ip를 가지고서 pod에 접근 할 수 있다. 왜 굳이 서비스의 ip를 통해서? 접근하지? pod는 쿠버네티스에서 시스템,성능 장애로 언제든 지 죽을 수 있고, 언제든지 재생성 될 수 있게 설계 되어있어서, pod의 ip는 신뢰성이 떨어지지만 서비스의 ip는 삭제되거나 재생성되지 않고, 사용자에 의해서만 삭제,재생성 된다. 서비스의 ip로 접근을 하면 항상 연결되어 있는 pod에 접근이 가능하다. 가장 기본적인 방식이 cluster ip 방식이 있다.

• Controller

Node에 pod가 있는데 이 pod가 다운이 되던가, pod가 스케쥴링되어있는 node가 다운이 되면 이 pod에 있는 서비스가 문제가 생기지만 즉각적으로 인지하고 다른 node에 새로 만들어주며 Auto Healing 기능이라고한다. 그리고 pod의 리소스가 limit 상태일때 컨트롤러는 이 상태를 인지하고 pod를 하나 더 만들면서 이 Pod를 하나 더 만들어주는데 이를 Auto Scaling 이라고 한다. 또 여러 pod에 대한 버전을 업그레이드 해야 할 경우, 컨트롤러를 통해서 한번에 쉽게 업그레이드가 가능하며, 업그레이드 중에 문제가 생기면 roll back 가능 한 기능을 제공한다. 일시적인 작업을 해야 할 경우 컨트롤러가 필요한 순간에만 pod를 만들어서 해당 작업을 이행하고 삭제를 한다. 그 순간에만 자원이 사용되고 작업이후 반환되기 때문에 효율적인 작업이 가능하다.

• Deployment

Recreate, Rolling Update, Blue/Green, Canary Recrate 방식은 Deployment를 만들게 되면 버전 1의 pod들이 만들어지고 pod 1개당 자원이 1개씩 사용이 되면, 이 방식으로 배포를 하게 되면 , 기존에 파드를 삭제하고 버전 2의 pod들이 만들어지게 때문에 down time이 발생하게 된다. 두번째 Rolling Update 는 v2에 pod를 1개 만들어주고 자원 사용량이 늘어난다. v1,v2 둘다 사용을 하고있기 때문에 누구는 v1,v2에 각각 접속하게 된다. 그리고 v1파드에서 1개삭제하고, v2에 파드를 하나 더 만들고, 남은 v1에 있는 pod를 삭제함으로써 서비스의 down time 이 없지만 잠깐의 자원사용량이 늘어난다는 점이 있다. Blue/Green은 컨트롤러를 만들어서 pod를 만들어서 pod에는 라벨이 있기 때문에 서비스의 셀렉터와 연결이 된다. 이렇게 운영이 되고 있는 상태에서 컨트롤러를 하나 더 만드는데 v2 버전으로 만들게 되면 기존의 두배의 사용량이 된다. 서비스의 라벨만 변경해주게 되면 바로 v2의 버전의 새로운 파드들과 연결이 된다. 순간적으로 연결이 되기때문에 서비스이 down time은 없고, 문제가 생길 시 v1으로 다시 라벨을 바꾸게 되면 롤백도 가능하다. 마지막은 Canary 배포가 있는데 v1에 대한 pod가 있고, 아까와 마찬가지로 v1에 대한 pod가 있고 v1에 한 라벨이있고 v1에대한 서비스에다가 라벨을 달아서 운영을 한다. v2에 대한 pod를 만들 때 라벨을 동일하게 만들면 v2에 대한 서비스 유입이 들어온다. 문제가 되면, controller의 레플리카 셋만 0으로 만들게 되면 유입되는 트래픽을 끊을 수 있다. v1은 v1 대로, v2는 v2대로 각각의 서비스를 만들고 ingress controller라고 해서 유입되는 트래픽을 이렇게 url path에 따라서 서비스에 연결을 해주는 역할을 하는 컨트롤러가 있는데 이렇게 되면 path앞에 v2를 달게 되면 새로 배포될 서비스를 이용할 수 있게 된다. 문제가 없으면 설정을 변경하고 기존에 v1에 대한 내용들을 삭제 하면 된다. 하지만 v1,v2의 필요한 자원량을 고려를 해야한다.

Deployment를 만들때 selector, replicas, template 의 값을 똑같이 넣게 된다. 이 값들은 이 Deployment가 pod를 만들어서 관리하기 위함이 아니고 Replicaset을 만들때 값을 지정하기 위해서다. 그래서 Replicaset은 본연의 역할대로 pod를 만들게 된다. 그리고 서비스를 만들어서 pod에 있는 라벨에 연결을 하면 서비스를 통해 pod를 접근 할 수 있게 된다. Deplyment의 templete에 pod를 v2로 바꾸게 되면 replicaset은 replicas를 0으로 만들게 되고 pod들은 삭제가 되서 down time이 발생하게 된다. 그리고 새로운 Replicaset을 만들게 되는데 변경된 v2의 pod를 넣기 때문에 pod들도 v2 버전으로 생성이 된다.

yaml 파일의 strategy : Recreate, RollingUpdate…