boan

[Service]

- 다른 app, 사용자 등과 통신할 수 있게 해줌

- frontend - backend - db 통신과 같은 pod 그룹이 서로 통신할 수 있게 해주는 역할

* 방법1 - NodePort

- 특정 포트를 지정해서 해당 Node_ip: port로 접속하면 지정된 pod에 접근

- 외부 통신 가능한 포트를 하나 만들어 준다고 생각하면 쉬움

- 범위: 3000~32767

* 방법2 - Cluster IP

- Cluster 내부 가상 ip 할당해서 해당 ip를 통해 내부 자원끼리 통신

- frontend, backend, db 등을 각각의 서비스로 묶었을 때, 각 서비스에 ip와 이름이 할당되는데 이를 cluster ip라 부름

- default 옵션

* 방법3 - LB

- LB 통해 통신 (csp 등에서 제공하는 lb)

- 각 Node ip로 접근을 하면, 사용자는 모든 node의 ip를 받아야하는데 하나의 url로 받기 위해 상단에 lb를 두는 것

- 상단 vm에 nginx 같은 거를 설치해서 lb로 사용 가능

- CSP에서는 LB를 제공하기 때문에 yaml 파일에서 LoadBalancer로 type 지정만 해주면 됨

[Service 생성 yaml]

- port는 반드시 입력, target port는 없으면 port와 동일하게 인식

- nodeport는 범위내에서 할당

- selector 통해서 어디 pod와 연결할지 명시

<참고>

- Pod가 여러개인 경우: label 통해서 해당 label 지닌 모든 Pod에 연결

- Node가 여러개인 경우: service가 모든 Node 해당하도록 생성, 해당 Node ip와 동일한 port를 통해 연결 가능

- 즉, Pod나 Node 개수에 따라 별도 설정 등 필요 없음

[endpoint]

- svc 입장에서는 pod로 연결하는 포인트(yaml에서는 label)

이번 섹션에서는 k8s 네트워크 관련한 내용을 정리했다.

k8s는 보통 Node, Pod에 각각 ip를 붙여준다.

Node ip는 ssh 접근 등을 위해 붙여준다.

참고로 Docker에서는 container에 붙이나 k8s는 container가 아닌 Pod에 붙인다.

k8s가 처음 설정될 때 사설 ip 설정하는데 주소 범위는 10.244.0.0이며, node 단위로 생성된다.

따라서 pod 끼리 내부 통신 가능하나, 다양한 변수가 있기 때문에 추천하는 방법은 아니라고 한다.

k8s 특성상 Pod가 생성 / 삭제가 불규칙하게 일어나는데 ip로 설정을 하면 여러 변수가 발생할 수 있기 때문이다.

여기서 주의해야 할 점은 노드 1,2에 있는 pod 1-1, 2-1은 같은 ip를 가질 수 있기 떄문에

각기 다른 Node 안에 있는 Pod가 통신할 경우, ip 충돌이 날 수도 있다.

 Node와 Container는 양방향 통신 가능해야 하는 것이 k8s가 원하는 방향인데, 이는 직접 구성해야 한다.

>> cluster 배포하는 플랫폼에 따라 기 개발된 솔루션(cisco, vmware nsx 등)을 이용할 수 있다.

이러한 솔루션으로 각 Node와 Pod는 unique ip 지니게 되고, 비로소 양방향 통신이 가능해진다.

이번 섹션에서는 yaml를 이용해 여러 객체를 생성하는 실습을 수행했다.

[기본 yaml 형식]

- api version

  :객체마다 필요로하는 버전이 다르니 주의해서 기입해야 함

   (e.g) Pod: v1 / ReplicaSet: apps/v1 / Deployment: apps/v1

- kind

  :생성하려는 객체명을 기입하며, 대소문자 구별하니 주의해야 함

   (e.g) Pod / ReplicaSet / Deployment

- metadata

   :객체를 구별하기 위한 데이터를 입력하는 곳으로 name과 label 등이 있음, dictionary로 기입

   (e.g) metadata:

              name: name_you_want

              labels: 

                 app: myapp

                 tier: bronze

- spec

  : 생성하려는 객체에 대한 실제 정보를 입력하는 곳으로, 객체에 따라 입력 내용이 다름

*객체 생성 yaml*

[ReplicaSet]

- 이전에는 Replication Controller이라는 유사 기능 사용했음, 현재는 ReplicaSet으로 변경되는 추세

- HA 보장을 위한 것으로, 항상 Pod가 설정 개수만큼 항상 실행될 수 있도록 함

- Pod가 아닌 Node도 관리 가능, 특정 Node 내 Pod가 모두 죽어도 다른 Node에서 해당 Pod 수행 가능하도록 함(LB 역할)

- yaml 파일 spec 부분에 - template(image 이름), replicas(수행 개수) 입력

<yaml 형태>

replica set - apiVersion: apps/v1

                    kind:

                    metadate:

                    spec:

                      selector: 

                        mathLabel:

                          type: podLabel (Pod Label 명)

                     replicas: (유지할 Pod 개수)

                     template: (Pod 내용)

* replicaset에 설정 된 개수를 유지시키기 위해 pod가 종료 / 추가 수행됨

[Deployment]

- ReplicaSet보다 큰 개념으로 upgrade 등을 seemless로 수행 가능하게 함설ㅈ

- Deployment가 ReplicaSet 제어, ReplicaSet이 Pod 제어

[Rollout]

- Deployment 변화 추적, 필요시 rollback할 수 있게 해줌, 관련된 어떤 활동을 다 Rollout이라 생각하면 편함

- 업그레이드 중 문제 발생 시 이전 버전으로 롤백

kubectl rollout undo deployment deployment-name

- 특정 revision으로 돌아가면, history 확인 시 해당 revision은 삭제되고 신규 revision 번호가 부여됨

   (= 동일한 명령어이기 때문)

[Deployment strategy]

- recreate: 구버전 모두 내린 후 신규버전 업로드 = 다운타임 생김

- rolling update: 구버전 내리고 신규버전 업로드 1개씩 반복 = 기본 전략

                           => rs를 하나 더 만들어서 교체하는 느낌임 (한번에 변경할 % 설정 가능)

<관련 명령어>

- yaml 파일 수행: kubectl creat -f file.yml

- 객체 생성: kubectl create  deployment httpd-frontend2 --image=http:2.4-alpine --replicas=3

- 객체 목록 확인: kubectl get all 

                            kubectl get replicaset

- yaml 파일 수정 내용 적용: kubectl replace -f file.yml 

                                             kubectl apply -f name.yaml  

- 설정 내용 수정: kubectl edit my-replicaset

                            kubectl scale --replicas=3 -f file.yml

                            kubectl scale --replicas=3 replicaset my-replicaset    

                            kubectl set image deployment deployment-name container_name=image_name 

- 상세 내용 확인: kubectl explain replicaset

- deployment 상태 확인: kubectl rollout status deployment deployment-name

- deployment 변경 내용 추적: kubectl rollout history deployment deployment-name

  (--record 옵션을 통해 변경 했어야 확인 가능)

- 테스트: kubectl run a --image=nginx --dry-run -o yaml > ab.yaml

               * --dry-run 옵션으로 실제 수행 / 수행x 방법으로 적용 가능 여부 확인, 관련 yaml 파일 생성 위해 redirection 사용