CKA 자격증을 요새 공부하는 중이다. udemy에서 관련 강의를 듣고, 실습 Labs에서 실습도 해보면서 하나씩 공부하고있다. 원래 kubernetes 구축과 간단한 사용법 정도는 알고 있었지만, 이번 기회에 개념을 좀 다지면서 하다보니 아키텍쳐 이해가 더 잘되고 머리속에 잘 박히는 것 같다. 그치만 양이 꽤나 방대해서 정리를 해두어야 까먹어도 나중에 볼 수 있을 것 같아서… 한동안 CKA 관련 포스팅을 해야겠다. 출제 비율이 가장 높은 부분인 Core Concepts 부분을 마쳤으니 정리를 해보자 Core Concepts 파트에는 아래와 같은 항목을 다룬다. 개념부터 실습을 다루고 있다. 순서대로 한번 정리해보자 PODs 정리는 강의를 통해 얻은 정보와 나의 느낌 위주로 되어있어… 100% 정확한 해석은 아니다. (영어 강의이기 때문에) Pod는 항상 표현하기를 kubernetes에서 가장 작은 단위라고 표현한다. 실제로 맞는 말이고 “작다” 라고 크기를 표현하는 것이 실제로는 아키텍쳐 상에서 가장 하위 레벨이라고 보면 된다. Kubernetes는 컨테이너를 만들고 앱을 파드에 담아서 띄운다. 파드를 띄우는 방법은 개별적으로 Pod를 띄울 수도 있고, ReplicaSet, Deployments를 이용할 수도 있다. 컨트롤러 없이 그냥 Pod를 띄우는 방법만 여기서 언급하면 크게 2가지이다. kubernetes 입장에선 1,2 방법이 다르진 않지만, 사용자에겐 아주 다르다. 1. 매니페스트 파일을 통한 배포 매니페스트 파일에 필수적으로 기입되어야 할 4가지가 있는데 apiVersion, kind, metadata, spec 이다. 위 예시가 아~~주 기본적인 양식이고, [ ] 에 적절히 기입해서 작성한다. labels은 무엇을 적든 상관은 없고, 본인이 필요한 것을 key : value 형식으로 적으면 된다. 이렇게 작성한 파일이 minujana.yaml 이라고 가정하면 이러면 kubernetes에서 컨테이너를 만들고 거기에 입력한 이미지와 이름으로 파드가 올라가게 된다. 이렇게 하면 파드의 상태를 조회할 수 있다.파드의 상세 정보를 보고싶으면 명령어로 파드의 image, node 등등 상세 정보를 볼 수 있다. 2. kubectl 커맨드를 통한 배포 이 정도 커맨드 입력만으로 파드를 띄울 수 있다. 이렇게 입력하게 되면 kubernetes에서 알아서 yaml파일을 작성하여 배포를 하는 방식이다. 이렇게 배포된 파드의 매니페스트 파일을 보고 싶으면 위 커맨드를 통해서 작성된 매니페스트 파일을 확인할 수 있고, 이렇게 디렉션을 주면 파일로 저장할 수 있다. 가장 좋은 방법은 개인적으로 dry-run 옵션을 주어서 기본적인 사항이 기입된 파일로 떨구고, 이 파일을 수정하여 매니페스트로 배포하는게 베스트라고 생각한다. (나중에 pod를 수정하거나 할 때 결국 매니페스트 파일이 필요하기 때문..) ReplicaSets 레플리카셋은 이름대로 복제하는 컨트롤러이다. Pod를 지정한 개수만큼 복제하고 지정한 개수를 항상 유지하는 역할을 하는 컨트롤러이다. ReplicaSet은 이보다 더 상위개념인 Deployment와 함께 이해하는게 개념이해를 돕는다. ReplicaSet 단독으로 쓰면 어떤 use-case가 있을지 고민을 좀 더 해보아야겠다. 현재까지 내가 느끼기엔 Deployment의 기능을 위한 부속품이다. 좀 복잡해보여도 ReplicaSets 매니페스트안에 Pod의 매니페스트를 추가한 것으로 생각하면된다. 앞서 말한 꼭 기입해야할 4가지 항목은 동일하다. 위 매니페스트 파일을 아래에서부터 봐야 이해가 쉽다. 파드는 busybox라는 이미지를 사용하고 이름은 busybox로 동일하다. 커맨드는 파드에 적용할 커맨드이며 이 예시에선 sleep을 걸어놓았다. 그리고 그 위 metadata를 보면 labels를 tier: frontend로 지정했다. busybox 파드는 모두 이 labes을 갖게 된다. 좀 더 윗 부분을 보면, Replicas 는 3이다 말그대로 3개의 파드를 띄우겠다는 뜻이고, selector는 파드를 선택하는 부분이다. 레이블이 tier : frontend 인 파드를 3개로 유지하는 설정이다. 그리고 가장 윗부분은 ReplicaSet의 Label과 name이다. ReplicaSet이 Pod를 Label로 선택한 것 처럼 나중에 나오는 Service라는 객체가 매니페스트 파일을 작성할 때 ReplicaSet과 Deployment의 Label을 참고하게 된다. Deployments Pods는 재시작이라는 것이 없고 delete와 run으로 기동한다. Pod의 수정사항이 생기면 이를 반영한 Pod가 새로 켜지고 기존에 있는 Pod는 지워지는 방식이다. 그래서 Pod만 단독으로 띄워서 쓰게되면 수정사항이 있을때 Pod를 지우고 새로 배포하여야 반영이 된다. ReplicaSet을 이용하면 공수가 1단계가 줄긴 한다. Pod를 지우면 알아서 갯수를 유지하기 위하여 컨트롤러가 Pod를 새로 띄운다. 따라서 새로 뜬 파드에만 수정사항이 반영이 되어있다. 이 부분을 테스트하기 위해서 MySQL 파드를 3개 띄우고 최초에 띄울 때에는 ROOT_PASSWORD를 입력하지 않고 띄워 파드가 뜰 때 에러가 발생하는데 이 상태로 매니페스트 파일에 env에 PASSWORD를 추가하고 반영한 후, 파드를 하나 지워보니 새로운 파드가 정상적으로 Running 되는 걸 확인했다. Deployment는 내가 원하는 동작을 정확하게 해준다. 매니페스트 파일을 적용하면 수정사항을 반영한 Pod를 순차적으로 띄우고 지우고 하며 롤링업데이트를 해준다고 보면 된다. 매니페스트 파일은 사실 ReplicaSet과 다른 것이라곤 이름 밖에 없다. 위의 ReplicaSet의 매니페스트 파일에서 만 바꾸면 Deployment의 매니페스트 파일이다. 내 뇌피셜에 의하면 kubernetes에서도 커맨드로 ReplicaSet을 만드는게 없는걸로 보아 Deployment의 부속품이라는 나의 가설에 좀 더 근거가 되는 느낌.. Deployment도 커맨드로 배포를 할 수가 있다. 줄 수 있는 옵션이 아주 많다. 따라서 image 정도 까지만 주고 아까 처럼 이렇게 파일로 받아서 나머지는 작성하는 것이 좋은 것 같다. Deployment는 앞서 이야기한 롤링업데이트 이외에도 롤백, pause, resume 같은 기능이 가능하게 해주는 컨트롤러이다. 지금은 전혀 찾지 못했지만, 나중에라도 ReplicaSet이 Deployment보다 좋은 점을 찾을 수 있을지 모르겠다..