Post

Linux 쿠버네티스(3)

Posted
By smth-hyj
9 min read
Linux 쿠버네티스(3)

워크로드 리소스

  • 워크로드 리소스
    • POD를 배포/관리하는 정책
    • POD를 workload를 발생시키고 이것을 어떻게 관리할지 다루는 것이다.
    • 쿠버네티스 워크로드 리소스는 컨트롤러를 사용하여 관리하는데, 컨트롤러는 파드를 관리하는 역할을 한다.

ex. $ kubectl create deployment webui —image=nginx –replicas=3

  • webui라는 deployment 정책이 있는데, replicas 옵션을 주면 nginx 이미지가 3개가 뜬다.

Relicaset

  • ReplicationController 보다 풍부한 selector를 제공한다.
  • ReplicationController가 그냥 해당 라벨과 일치하는지만 봤다면, 이는 key, operator, values를 고려함.
  • matchExpressions 연산자(operator)
    • In
    • NotIn
    • Exists
    • DoesNotExist
  • rolling update을 지원한다.(이때, deployment를 지원한다.)
    • rolling update: 쿠버네티스 배포 방식 중 하나로, 점진적으로 케이스를 지워 그 자리에 새 버전을 채우는 배포 방식을 뜻한다.
  • examples
    • kubectl delete rs rs-nginx –cascade=false
      • 케이스만 삭제, 단독파드가 됨.
  • Replicaset은 Pod 그룹의 구성이 짜져있는 틀이다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: rs-nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: webui
  template:
    metadata:
      name: nginx-pod
      labels:
        app: webui
    spec:
      containers:
      - name: nginx-container
        image: nginx:1.14

Deployment

  • Pod(Container) ⊂ ReplicaSet ⊂ Deployment
    • Replicaset으로 파드를 관리하고 Deployment로 Repliaset을 관리한다.
  • Replicaset을 컨트롤해서 Pod수를 보장한다.
  • Rolling Update와 Rollback 지원(버전업)
  • 만약 deployment가 외부로 노출되면, 업데이트가 이루어지는 동안 사용 가능한 파드에게만 트래픽을 로드밸런스 한다.
  • Rolling Update/Rollback을 할 경우, 순차적으로 파드가 업데이트 되면서 그 전에 쓰던 Replicaset만 남게 되는 현상이 발생한다. 남은 Replicaset을 통해 롤백을 진행한다.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deploy-nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: webui
  template:
    metadata:
      name: nginx-pod
      labels:
        app: webui
    spec:
      containers:
      - name: nginx-container
        image: nginx:1.14

Statefulset

  • 리소스에 특별한 값들이 유지되어야 할 때, DB는 statefulset이고 그 외 나머지는 deployment이다.

ReplicationController, Daemonset, Job, CronJobs

REplicationController

  • 컨트롤러 중 가장 순수하게 개수를 보장한다.
  • 만일 지정된 개수보다 많으면 파드를 제거하고, 반대로 너무 적으면 개수에 맞게 파드를 시작한다.
  • 파드를 추가할 때는 template(컨테이너에 대한 정보가 담긴 곳)을 이용해 pod를 추가한다.

  • 기본 구성

    1
2
3
4

    spec:
  replicas: # 레이블을 가진 selector 개수를 유지하는 것
  selector: # metadat안에 정해진 많은 레이블 중 원하는 레이블만 골라서 보기 위해
  template: # 컨테이너 정의

[참고]

  • scale in/out : e.g. PC 개수 늘리기 / 줄이기
    (우리가하는방식 동일한 방식을 가지고 개수를 늘려가고 있음)
  • scale up/down : e.g. PC 사양 높이기 / 낮추기

Daemonset

Job

CronJobs

서비스

  1. 쿠버네티스 서비스(Service)
    • 쿠버네티스 서비스
      1. 파드 그룹에 대해 단일 진입점(Virtural IP)을 제공
      2. 외부에서 클러스터 내에 파드 그룹에 접근 할 수 있도록 기능 제공
  2. 서비스 종류
    • 서비스 종류
      1. Cluster IP » VIP 제공 (외부 -> 내부)
      2. NodePort » VIP + NodePort 제공 (외부 -> 내부)
      3. LoadBalancer » VIP + NodPort + LB’s IP (외부 -> 내부)
      4. ExternalName » 도메인 매핑 (내부 -> 외부)

클러스터 IP - VIP만

  • 파드 그룹(같은 Label)에 대해 단일 진입점을 제공한다.
  • 단일 진입점(VIP)는 사설 IP로 제공된다.(ex. 10.233.0.0/18)
  • 클러스터 IP는 디플로이먼트(파드 그룹, 같은 레이블들에 매핑된 파드들) 앞 단에 아이피를 하나 둬서 그 아이피를 향해 날아온 패킷들이 실상 여러개의 파드(파드 그룹 속에 있는)에 로드밸런싱된다.

서비스의 포트 혹은 클러스터 IP의 포트

  • 예제
1
2
3
4
5
6
7
8
9
10
11
12
13

apiVersion: v1
kind: Service
metadata:
  name: webui-svc
spec:
  # type: ClusterIP
  # clusterIP: 10.233.10.10
  selector:
    app: webui
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80

Nodeport - VIP + NodePort

  • 파드 그룹(같은 label)에 대해 단일 진입점(VIP)을 제공한다.
  • 노드의 IP:Port(30000-32727)로 요청하면 파드 그룹(같은 Label에 대한 부하 분산을 제공한다.)
  • 파드가 들어있는 노드의 특정 포트(특정 포트의 대역은 30000-32727)로 들어가서 로드밸런싱함

LoadBalancer - VIP + NodePort + LB’s IP

  • 파드 그룹(같은 label)에 대해 단일 진입점(VIP)을 제공한다.
  • 노드의 IP:Port(30000-32727)로 요청하면 파드 그룹(같은 Label에 대한 부하 분산을 제공한다.)
  • LB(VM(Haproxy), Container(Metallb))로 요청하면 파드 그룹(같은 Label)에 대한 부하 분산을 제공한다.
  • LB는 VIP와는 다르다.
    • VIP : 파드 그룹을 묶는(같은 라벨로 묶인 파드들) 가상 IP
    • LB : LB는 노드들을 잇는 네트워크 시스템 안밖으로 나가는 네트워크를 관리하는 L4 스위치
  • 예제
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

---
apiVersion: v1
kind: Service
metadata:
  name: loadbalancer-service
spec:
  type: LoadBalancer
#  clusterIP: 10.233.10.10
  selector:
    app: webui
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
#    nodePort: 30200

ExternalName

ExternalName == DNS CNAME

  • (내부 -> 외부/내부) DNS CNAME 등록 작업(서비스 이름 < 매핑 > DNS 이름)
    • pod ex. podname.default.pod.cluster.local < 매핑 > google.com
    • svc ex. svcname.default.svc.cluster.local < 매핑 > naver.com

[참고] netshoot 이미지 = 트러블 슈팅 용도로 가장 많이 사용되는 이미지

Headless 서비스

  • 단일 진입점(VIP)이 필요없는 경우 사용한다. => DB Pod
  • 셀렉터(selector)가 필요 없는 경우 => DB 연결

[ 참고 ] Headless vs ExternalName

  • headless -> DNS A Record
  • ExternalName -> DNS CNAME Record

Headless는 거의 보안상 쓰인다.

Network(네트워크)

  • kube-proxy
    • worker node 안에 Pod에 연결할 때 사용하는 네트워크를 책임진다.
    • (ㄱ) 마스커레이드(Masquerade) (ㄴ)로드벨런싱(포트포워딩)(Port Forwarding)
  • Kube-proxy 모드
    • iptables 모드 » iptables CMD (Debian, Ubuntu 계열)
    • ipvs 모드 » ipvsadm CMD (Redhat 계열)
국비, kubernetes
container pod kubernetes k8s 쿠버네티스
This post is licensed under CC BY 4.0 by the author.