책보고 따라해보는 쿠버네티스: (2) 시작하기

시작해보자 쿠버네티스 으쌰

 

출처: 시작하세요 도커/쿠버네티스 - 용찬호 지음

 

모든 리소스는 오브젝트 형태로 관리된다고 한다.

minio 라는 object storage 를 사용한다는 말을 들었는데 이거 때문인것 같음

 

아래와 같은 것들을 하나의 오브젝트로 사용할 수 있다는데 명령어로 확인 가능하다

- Pods # 컨테이너집합

- Replica Set # 컨테이너 집합 관리하는 컨트롤러

- Service Account # 사용자

- Node # 노드

$ kubectl api-resources # 사용할 수 있는 오브젝트 확인 (많군.. 다쓰는건지는 아직 모른다고 적으려고하려는 찰나 다음장에 보니 자주쓰는것만 알면 된다고 함, 필요한 것들은 공홈에서 보고 배우라고.. I got it)

$ kubectl explain <오브젝트명>으로 특정 오브젝트 설명을 볼 수 있다고 한다.

kubectl api-resources 결과 뭔지 모를 오브젝트들 많았다.

 

YAML 활용

컨테이너 뿐만 아니라 거의 모든 리소스 오브젝트에서 사용할 수 있다는 것이 가장 큰 특징. kubectl보다 YAML로 적용하는 방식이 사용되다보니 YAML 파일 작성 잘하는 것 = 쿠버네티스 잘하는것 이란다. 

yaml? 스프링부트에서 properties 파일 변경해서 썼었는데? 갑자기 할 수 있을것 같다. 근자감 +1

 

kubelet 

모든 에이전트(마스터, 워커)에서 실행되며 컨테이너 생성,삭제 및 마스터-워커 노드 간 통신역할 담당. 이게 안되면 연결이 안되는거 ㅇㅇ

 

컨테이너 애플리케이션 구동을 위해 반드시 알아야하는 오브젝트

1) Pod # 컨테이너 애플리케이션 배포하기 위한 기본 단위. 1개의 Pod(포드)에 컨테이너가 N개 올수 있다.

2) Replica Set #

3) Deployment

4) Service

 

 

1. Pod

쿠버네티스의 기본단위. 여러개의컨테이너를 추상화해 하나의 애플리케이션으로 동작하도록 만드는 컨테이너 묶음

nginx-pod.yaml

$ kubectl apply -f nginx-pod.yaml 로 적용해준다 

 > pod/my-nginx-pod created 메시지가 나오면 정상

$ kubectl get pods 로 현재 pod 리스트를 확인한다

Ready 1/1인 my-nginx-pod가 한개 생성되었다.

$ kubectl describe pods my-nginx-pod 로 상세정보 확인가능하다.

$ kubectl exec -it my-nginx-pod bash # my-nginx-pod에서 bash 셸을 실행하고 -it옵션으로 이를 유지하도록 하면 컨테이너 내부로 들어갈수 있다.

$ kubectl logs my-nginx-pod #nginx서버에 접근했던 기록들이 찍힌다.

$ kubectl delete -f nginx-pod.yaml #nginx 파드를 삭제한다. yaml 자체가 삭제되는것은 아님

 

파드는 완전한어플리케이션이다.

하나의 어플리케이션 동작에 필요한 주컨테이너 + 부가기능을 위한 모든 컨테이너들을 사이드카 컨테이너를 붙여서 모두 같은 워커노드에서 실행하도록 하며, 다른 컨테이너들과 네트워크 환경등을 공유하도록 한다. 

--> 관계없는 컨테이너는 다른 파드로 빼라는 말인듯

 

 

2. ReplicaSet

레플리카셋은 느슨한 연결로 일정수의 포드를 유지하는 컨트롤러다. 

노드 장애등으로 일정수로 정해진 파드의 개수가 줄을 경우 이를 자동으로 생성도 해주고 초과되면 삭제도 해준다. 

yaml변경해서 replicaset의 수를 3->4로 변경하면 기존 레플리카셋은 유지한채 1개의 레플리카만 추가된다.

 

첫 ReplicaSet, replicaset-nginx.yaml

spec 의 replicas에 3으로 했더니 pod가 3개가 생성되었다. 

replicaset-nginx-4pods.yaml

앞에 작성한 yaml파일을 재활용해서 replicaset yaml을 만들자

$ cp replicaset-nginx.yaml replicaset-nginx-4pods.yaml

vi 편집기로 replicas: 4로 수정후 저장하고  # kubectl apply -f replicaset-nginx-4pods.yaml로 적용하니

replicaset.apps/replicaset-nginx configured 라는 메시지가 나오면서, 하나의 pod만 추가가 되었다.

지정된 pod 수를 유지하려는 성질이 있다는것.. selector.matchLabels.app 에 이름 바뀌면 다른 app으로 인식되어 pod가 새로 추가된다.

$ kubectl get po --show-labels로 라벨이름 확인이 가능하다.

$ kubectl get pods -l app=my-nginx-pods-label #특정라벨만 조회도 가능

$ kubectl delete rs replicaset-nginx #지울때 rs는 레플리카셋인듯

 

$ kubectl get po 에서 po=pods 줄임말 인듯

 

3. Deployment

첫 Delployment, deployment-nginx.yaml

왜 replicaset 놔두고 상위개념으로 deployment를 만들었냐? =>업데이트와 배포가 편해지므로

 

$ kubectl apply -f deployment-nginx.yaml

$ kubectl get deploy 로 보면 디플로이먼트가 생성이 되었고, #kubectl get replicasets으로 보면 레플리카도 3개가 조회됨, # kubectl get po 로 보면 파드도 3개 생김

$ kubectl delete deploy mt-nginx-deployment #지울때.. 파드까지 cascading 하게 지워진다

 

아직까지는 뭐가 좋아졌는지 모르겠으나

 

$ kubectl apply -f deployment-nginx.yaml --record 

--record 옵션이 붙으니 기록이 남기 시작한다

$ kubectl set image deployment my-nginx-deployment nginx=nginx:1.11 --record로 yaml 을 수정하지 않고도 이미지 버전 변경도 가능하고, (= yaml파일 열어보면 버전 1.10 그대로이나 파드에는 1.11 적용되었단 말)

위의 액션들이 다 기록이 되서

$ kubectl rollout history deployment my-nginx-deployment 로 보면 체인지 히스토리도 보이고..

$ kubectl rollout undo deployment my-nginx-deployment --to-revision=1 로 다시 원복도 가능하다

$ kubectl describe deploy my-nginx-deployment로 레플리카셋 생성된것 이름 확인 가능하다

 

4. Service

파드에 접그할 수 있는 규칙을 정의

- ClusterIP 타입: 쿠버네티스 내부에서만 포드들에 접근할때 사용, 외부 포드 노출 X

- NodePort 타입: 포드 접근 포트를 클러스터 모든 노드에 동일하게 개방. 접근포트는 랜덤으로 정해짐

- LoadBalancer 타입: AWS, GCP 같은 클라우드 환경에서만 사용 가능. 로드밸런서를 동적으로 프로비저닝해 포드에 연결..  부하체크해서 시스템 리소스 분배해주는게 잘된다는 이야기인듯

deployment-hostname.yaml

위와 같은 디플로이먼트를 하나 작성해서..

$ kubectl apply -f deployment-hostname.yaml로 적용

$ kubectl get pods -o wide # -o wide 옵션주니 IP, NODE, NOMINATED NODE, READING GATES 열이 더 보임

 

$ kubectl run -i --tty --rm debug --image=alicek106/ubuntu:curl --restart=Never curl 10.44.0.2 | grep Hello 

 

1) Cluster IP 타입

쿠버네티스 클러스터에서만 사용할 수 있는 IP가 생성되고, 이 IP로 연결된 파드들(1:1아니나 한번에 한개씩 랜덤인듯)에 접근할 수 있게된다.

hostname-svc-clusterip.yaml

app: webserver라고 지정하면 webserver라는 label을 찾기 때문에 위에서 작성한 파드에 접근이 가능해진다. 

 

$ kubectl apply -f hostname-svc-clusterip.yaml 로 적용

$ kubectl get services 로 확인

kubectl get services 결과

새로 생긴 hostname-svc-clusterip 서비스의 IP와 Port로 접근가능

$ kubectl run -i --tty --rm debug --image=alicek106/ubuntu:curl --restart=Never -- bash

서비스 IP:PORT로 접근하고 있고 호스트네임이 바뀌는것에서 별도 설정없이 로드밸런싱이 되는것 확인

$ curl hostname-svc-cluterip:8080 --silent | grep hello

내부 DNS 이용해서 IP 정보 없이 NAME으로 포드나 서비스를 찾을 수 있다. => GOOD

 

$ kubectl delete svc hostname-svc-clusterip

 

2) NodePort 타입 서비스

마지막 type만 NodePort. hostname-svc-nodeport.yaml

타입만 NodePort로 변경하고 # kubectl apply -f hostname-svc-nodeport.yaml로 생성하니

$ kubeclt get services 결과에 hostname-svc-nodeport라는 이름이 하나 추가되었다. 포트가 8080:31140/TCP로 외부가 연결된것 같다

모든내드에서 내부IP 또는 외부IP 에 해당 포트로 접근이 가능해졌다

$ kubectl get nodes -o wide 로 조회하면 INTERNAL-IP, EXTERNAL-IP 등이 함께 조회된다. 내 경우 External-IP가 <None> 으로 조회되는데 이거는 다른 설정의 이유인것 같다..

 

NodePort 타입서비스는  ClusterIP 서비의기능을 포함하고 있다. 그래서 CLUSTER-IP 부분에 IP가 찍히는것

 

3) LoadBalancer 타입 서비스

클라우드에서만 사용된다하여 일단 패스

metadata.annotations: service.beta.kubernetes.io/aws-load-balancer-type: "nlb"라고 설정하면 네트워크 로드밸런서 사용가능해진다고 한다.

 

4) ExternalNmae 타입 서비스

서비스가 외부 도메인을 가리키도록 설정

spec.type: ExternalName

spec.externalName: my.database.com 이렇게 하면 별개 존재하는 레거시에 연동 가능해진다

 

 

** 이제까지 작성한 리소스 삭제

$ kubectl delete deployment,pod,rs --all