Kubernetes - 개념

https://subicura.com/2019/05/19/kubernetes-basic-1.html

https://subicura.com/k8s/guide/#%E1%84%80%E1%85%A1%E1%84%8B%E1%85%B5%E1%84%83%E1%85%B3

https://bcho.tistory.com/1256?category=731548

 

위 블로그를 보고, 요약했다.

 

1. 개념

Kubernetes란?

쿠버네티스Kubernetes - container를 관리해 주는 도구, container orchestration tool이다. 배포 방식도 여러가지가 있고, 클라우드에서 지원하기 때문에 구글의 경우 GKE, AWS의 경우 EKS, Azure의 경우 AKS를 지원하며, autoscaling과 loadbalance를 이용할 수 있다.

또한 namespace를 이용해 cluster를 test, stage, real 서버를 구분해서 쓸 수 있다.

 

- desired state

kubernetes는 desired state, current state를 이용해 container를 관리한다. 각각의 container의 current state를 보고 동일하면 아무것도 하지 않고, 다르다면 desired state로 만들기 위한 로직을 수행한다.

그렇기 때문에 선언형declarative 문법을 이용한다.

 

- Pod

kubernetes에서 배포할 수 있는 가장 작은 단위, pod 내에 있는 container들은 stoarge, network를 공유하며 localhost로 접근할 수 있다고 한다. container화된 application이라 생각하면 될 것 같다.

 

- ReplicaSet

pod를 여러 개로 복제해 사용하는 object이다. pod 개수를 유지하기 위해서는 replicaset을 이용한다고 한다.

 

- Service

pod를 외부 network와 연결해 주고 pod의 load balancer를 쓸 때 사용한다고 한다. loadbalancer라 생각하면 될 것 같다.

 

- 배포 방식

yml 파일에 desired state를 작성한다.

 

- architecture

kubernetes는 전체 cluster를 관리하는 master와 container가 배포되는 node가 있다. 호출하는 모든 명령은 master를 호출하고, node와 master가 통신하면서 명령을 수행한다.

 

kubectl <-> master (API server) <-> Node (kubelet <-> pod)</-></-></->

 

- master

보통 3대를 구성한다고 한다.

 

- node

node는 필요할 때 pod를 생성하고 network, volume을 설정한다.

 

 

 

---

 

 

 

2. 기본 명렁어

Kubectl은 kubernetes의 상태를 확인하고, 명령을 보내는 것이다.

 

- apply

kubectl apply -f {파일명}

원하는 상태 적용. 원하는 리소스 상태를 yml로 작성하고 해당 파일명을 호출하면 된다.

 

- get

kubectl get {type}

리소스 목록 출력. type에는 pod, service, 등등 여러가지가 들어갈 수 있다.

 

- describe

kubectl get {type/name}

리소스 상태 자세히 보여주는 명령어. type이나 이름을 치면 된다.

 

- delete

kubectl delete {type/name}

리소스 제거

 

- logs

kubectl logs {pod name}

컨테이너 로그 확인

 

- exec

kubectl exec (-it) {pod name} -- {command}

컨테이너에 명령 전달

 

- config

kubectl 설정 관리

 

 

 

---

 

 

 

3. Pod

kubernetes의 제일 작은 배포 단위. 한 pod에는 여러 개의 container가 들어갈 수 있다.

pod 내의 container는 IP, port, volume을 공유한다.

 

testpod.yml

apiVersion: v1
kind: Pod
metadata:
  name: test
  labels:
    app: test

spec:
  containers:
    - name: test
      image: {image}
      ports:
       - containerPort: 8080

 

kubernetes는 자원 관리 시 name, label을 이용한다고 한다. 위 yml 파일을 설명하자면

 

- version

object 버전. 내맘대로 적으면 된다.

 

- kind

object 종류. pod, replicaset, deployment, service, ... 등등이 있다.

 

- metadata

name과 label로 구성되어 있으며, 이 name, label로 object를 식별/관리한다. name은 이 pod의 name, label은 다른 service에서 식별할 라벨이다.

 

- spec

상세 명세이다.

 

kubernetes에서 livenessProbe라는 옵션을 이용하고 path와 port로 http get method를 보내서 확인한다.

 

 

 

---

 

 

 

4. Replicaset

yml 파일의 type을 ReplicaSet으로 바꾸면 된다.

 

testRS.yml

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: test-RS
spec:
  replicas: 1
  selector:
    matchLabels:
      app: test
      tier: app
  template:
    metadata:
      labels:
        app: test
        tier: app
    spec:
      containers:
        - name: test
          image: ~~~

 

- spec/replicas : pod 개수

- spec/selector : label 체크 조건. 이 조건이 만족하는 pod 개수를 spec/replicas만큼 만든다.

- spec/template : pod 명세

 

실제로 replicaset을 사용하지는 않고, deployment 내의 replicaset을 이용한다고 한다.

 

 

 

---

 

 

 

5. Deployment

마찬가지로 kind를 Deployment로 바꾸면 된다.

 

testDP.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-DP
spec:
  replicas: 3
  selector:
    matchLabels:
      app: test
      tier: app
  template:
    metadata:
      labels:
        app: test
        tier: app
    spec:
      containers:
        - name: test
          image: ~~~

 

- rolling update

app을 구성하는 것 중에 일부를 조금씩 update하는 것.

spec/strategy/type:으로 지정할 수 있다.

 

testDP-RU.yml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-DP
spec:
  replicas: 10
  selector:
    matchLabels:
      app: test
      tier: app
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 3
      maxUnavailble: 3
  template:
    metadata:
      labels:
        app: test
        tier: app
    spec:
      containers:
        - name: test
          image: ~~~

 

- spec/stragegy/rollingUpdate/maxSurge

업데이트 시 '새 버전 pod 작성' - '구 버전 pod 삭제' 이렇게 되는데, 총 pod의 합계를 나타낸다.

 

- spec/stragegy/rollingUpdate/maxUnavailable

사용하지 않아도 괜찮은 pod 개수. 위 yml의 경우에는 업데이트 시 10개 pod 중 7개만 사용하겠다는 말이다.

 

- blue/green update

버전 다른 2개 app을 가동시켜둔 뒤 network 설정을 변경하는 방식.

 

 

 

---

 

 

 

6. Service

cluster에서 pod로 접근할 떄는 service를 이용한다. service는 kubernetes network를 관리하며, 이 service를 통해 pod로 접근하는 것을 추천한다. service 중 loadbalancer는 service에 해당하는 IP:포트번호로 접근하며 각 pod에 대한 분산을 수행해 준다.

spec/selector에 적은 label을 가지고 있는 pod만 선택해서 service에 묶어주고, 이 pod들로 load balancing하는 것이다.

마찬가지로 kind를 Service로 만들어 준다.

 

testS.yml

apiVersion: v1
kind: Service
metadata:
  name: be
spec:
  ports:
    - port: 8081
      protocol: TCP
      targetPort: 8080
  selector:
    app: test
    tier: app

- spec/ports/port

service의 port

 

- spec/selector

service가 접근할 pod의 label 조건

 

- spec/targetPort

service를 어디에가 연결할지.

 

이렇게 service를 만들고,

nodeport를 만들고, - service로 접근하기 위함.

loadbalancer를 만든다 - nodeport(node)중 부하가 적은 것을 고르기 위함

 

위 예시는, name: be인 service를 만들고(metadata), app:test, tier:app인 pod만들 선택해서 service를 만들고, 8081 포트로 들어오는 요청을 컨테이너 8080 포트로 연결하겠다는 것이다.

 

 

 

 

 

 

 

결론적으로 deployment를 이용해 update에 대한 방식을 지정하고, replicaset을 이용해 여러 pod를 만들 수 있다.

다음으로 deployment를 관리할 service를 이용해 pod에 접근한다.

 

 

 

---

 

 

 

7. volume

pod 데이터는 pod를 제거하면 다 날아간다. 그러나 DB는 데이터가 있어야 한다. 따라서-kubernetes volume을 이용한다. AWS의 경우 EBS를 이용한다.