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 사용

YAML: data를 나타내는 파일 형식으로 JSON, XML과 동일하지만 다른 표현 방법이라고 생각하면 편함

[data 표현 방법]

1. Key:Value

    key:(스페이스)value

2. Arrays/Lists

    a:

      - sss

    * 대쉬가 있어야하며, ordered 형식임

3.Dictionary/Map

    a:

      b: 2

    c: aesd

    * 무조건 앞에 스페이스 있어야 하며, 같은 레벨로 기입해야 함

    * identation이 더 있다는 것은 상위의 속성이라는 의미이기 때문에 확인 필수 (python 유사)

    * unordered 형식임

4. comment

    #: comment

    * 주석 표기 방법

위의 3개 항목을 혼합해서 사용할 수도 있음

마지막 Health 항목은 List와 Dictionary를 혼합한 경우로, 모든 표기 방법에 익숙해지는 게 좋다

k8s 기본 실습, 나는 Windows 환경에서 수행했고 설치 방법은 아래 링크를 참조하면 된다.

k8s설치: https://kubernetes.io/docs/tasks/tools/install-kubectl-windows/

minikube 설치: https://minikube.sigs.k8s.io/docs/start/?arch=%2Fwindows%2Fx86-64%2Fstable%2F.exe+download

[Windows 환경변수 설정 방법]

고급 시스템 설정 보기 > 고급 > 환경변수 > 시스템 변수 내 Path 선택 후 편집 > 찾아보기 > minikube 설치 경로 추가

[설치 후 수행]

[실습 구조]

[참고]

node = master & worker node

pod = container를 실제 지니고 있는? 것이라 할 수 있음

CKA 획득을 하려 Udemy 쿠버네티스 강의를 등록했는데,

쿠버네티스 지식이 없으면 Beginner 코스가 있는데 이를 듣고 CKA 강의를 들으면 된다.

나는 쿠버네티스에 대한 지식이 거의 없어 Beginner부터 등록했고, 열심히 수강해보려 한다 :)

[Kubernetes 정의와 등장 이유]

- Kubernetes = k8s 라고도 불리며, 이는 k와 s 사이에 8개 알파벳이 있어 이렇게 표기

- 서비스에 필요한 웹서버, DB에서 호환되는 OS, 필요한 라이브러리 버전 다양화의 이슈로 인해 등장

- k8s = container orchestration 기술 = container 배포, 개수 조절 등 기능

[Docker의 구조]

- Docker = lxc container

  >> 하위 level 컨테이너라 설정 어려움

- 구성: OS kernel + software set 

  >> 단인 HW에서 여러 SW가 돌아가는 것

  >> SW의 경우 각 OS를 구별하게 하는 다양한 요소를 지니고 있음

  >> Linux 커널에 SW set이 달라 Ubuntu, Debian, Red hat 등으로 구별되는 것(= 다른 Linux 배포판)

       = Windows는 커널을 공유하지 않기 때문에 Linux 위의 container로 실행 불가능

       왜? Docker는 sw 부분에서 나누는 것이고 아래는 같아야 하기 때문

       VM은 커널 단계부터 분리하기 때문에 Linux, Window 같이 가능

[가상화의 장점]

- 기존 dev > ops로 이동시 관련 dependency 등 전달해야 하나 docker image 전달로 ops에서 쉽게 설정 및 배포 가능

[Node]

- Node = k8s가 설치된 vm 혹은 hw, 그 안에 여러 container 띄워짐

  >> Node 죽으면 container 다 죽음 = 서비스 장애 발생, 따라서 2개 이상이어야 하고 이런 Node 집합을 Cluster라 부름

- Master Node = k8s 설치된 또 다른 노드로 cluster 관리하는 역할

- Worker Node = 실제 서비스 등이 올라간 Node

[k8s 구성 요소]

- 실제 구성 요소 = 설치할 때

- API 서버 = front-end 같은 서버

- etcd = Cluster 관리에 필요한 데이터 저장

- Scheduler = 새로 배포된 container 찾아 Node에 할당

- Controller = 죽은 자원 있는지 확인 후 해당 자원 새로 올릴지 결정

- Container Runtime = container 실행을 위한 sw, e.g: Docker

- kubelet = 각 Node에서 실행되는 Agent, container가 Node에서 실행되는지 확인하는 역할

(빨강은 Mater-Node, 파랑은 Worker-Node)

[기본 명령어]

kubectl run = cluster에 app 배포

kubectl cluster-info = cluster 정보를 보는데 사용

kubectl get nodes = node 모두 열거

[Docker vs Container d]

- cri(container runtime interface) : 어떤 container runtime이든 지원(oci 사양 충족하는 경우)
- oci(open container initiative): imagespec과 runtimespec으로 구별

  >>imagespec: image 만드는 spec = image 빌드되는 사양, runtimespec: container runtime이 개발되어야 하는 사양

- dockershim: oci 기준 전 개발된 docker가 k8s 사용 가능하도록 지원하는 임시 툴

  >> 이를 위한 관리가 불필요하여 관련 지원 중단, 그 부분이 container c

- oci 기준 준수하는 container d, 이는 docker와 별개이며 ctr이라는 명령어 사용 (디버깅 위해서만 사용하는 명령어)
- nerdctl: container d에서 사용하는 명령어로 기존 docker 명령어와 유사, 신규 기능에 접근 가능한 장점이 있음

- crictl: cri와 상호작용을 위함 = k8s와 관련된 것으로 볼 수 있음, container runtime 관리 및 디버깅에 사용