[CKA] Core Concepts - 2

CKA (https://www.credly.com/org/the-linux-foundation/badge/cka-certified-kubernetes-administrator)

 

Kubelet

• Kubelet 은 마스터십의 유일한 연락망으로서 주 운항 일정 관리자(스케줄러)의 지시에 따라 선박에 컨테이너를 싣거나 내리는 역할을 한다.
• 선박의 상태를 일정 간격으로 보고한다.
• 쿠버네티스 클러스터로 노드를 등록한다.
• 노드에 컨테이너나 파드를 로드하라는 지시를 받으면 컨테이너 런타임 엔진에게 필요한 이미지를 끌어와 인스턴스를 실행하라고 요청한다.
• Kubelet은 파드의 상태와 컨테이너를 계속 모니터링하고 동시에 kube API server에 보고한다.
• ps -aux | grep kubelet 으로 설정을 확인할 수 있다.

 

Kube-proxy

• 쿠버네티스 클러스터 안에서는 파드 네트워킹 솔루션을 통해 각 파드가 서로 닿을 수 있다.
• 파드 네트워크는 내부 가상 네트워크로 모든 파드가 연결되는 클러스터 내 모든 노드에 걸쳐있다.
• 이 네트워크를 통해 서로 통신할 수 있다.
• kube-proxy는 쿠버네티스 클러스터의 각 노드에서 실행되는 프로세스다.
• 보통 파드에서 파드로 접속할 때 서비스를 설정해서 접속하는데 kube-proxy는 새 서비스가 생성될 때마다 각 노드에 적절한 규칙을 만들어 그 서비스로 트래픽을 전달한다.
• kube-proxy 는 세 개의 모드가 있다.
  • userspace
    • userspace는 클라이언트에서 서비스의 클러스터 IP를 통해 요청을 하면 iptables를 거쳐서 kube-proxy가 요청을 받는다.
    • 그리고 서비스의 클러스터 IP는 연결되어야 하는 적절한 파드로 연결해준다.
    • 이 때 요청을 파드들에게 나눠줄 때 Round Robin 방식을 사용한다.
  • iptables
    • userspace 모드와 다른 점은 kube-proxy가 iptables를 관리하는 역할만 한다는 것이다.
    • 직접 클라이언트에서 트래픽을 받지 않고 클라이언트 트래픽은 iptables를 거쳐서 파드로 직접 전달된다.
    • 그래서 userspace 모드 보다 요청 처리 성능이 좋다.
    • userspace에서는 파드로의 연결 요청이 실패하면 kube-proxy가 다른 파드에 연결을 재시도 한다. 하지만 iptables 모드에서는 연결 요청이 실패하면 재시도 하지 않고 요청이 실패한 채로 끝난다.
  • IPVS
    • IPVS는 리눅스 커널에 있는 L4 로드밸런싱 기술이다.
    • 리눅스 커널 안 네트워크 프레임워크인 넷필터(Netfilter)에 포함되어 있다.
    • 커널 스페이스에서 동작하고 데이터 구조를 해시 테이블로 저장하기 때문에 iptables 모드보다 빠르고 좋은 성능을 낸다. 더 많은 로드 밸런싱 알고리즘이 있어서 이를 이용할 수도 있다.
• kubectl get daemonset -n kube-system 으로 kube-proxy 를 확인 가능하다.

 

Pods

• 파드는 앱의 단일 인스턴스이며, 쿠버네티스에서 만들 수 있는 가장 작은 물체이다.
• 보통 애플리케이션이 파드의 단위로 배포가 되며, 애플리케이션을 추가하게 된다면 새로운 파드가 추가된다.
• 유저가 더 증가해서 현재 노드가 충분한 용량이 아닐때는? 새 노드를 추가하면 된다.
• 보통 파드는 앱을 실행하는 컨테이너와 일대일 관계를 맺게된다. 애플리케이션이 추가된다고 하면 컨테이너를 추가하는 게 아니라 파드를 여러 개 추가 하면 된다.
• 그렇다고 파드 하나에 무조건 하나의 컨테이너만 들어가는 것은 아니다. 기존에 있는 애플리케이션을 Support 하는 컨테이너가 동일 파드에 들어가기도 한다.
• Support 컨테이너는 사용자와 데이터 처리, 사용자가 업로드한 파일 처리 등등의 역할을 하기도 한다.
• 기존에 도커에서 이를 하기 위해서는 app 컨테이너와 Support 컨테이너를 따로 띄워서 link를 해줘야만 했다.
• 이 작업은 공수가 들어가고 또 link 된 app 과 Support 는 어느 한 쪽이 죽게되면 나머지가 쓸모 없어져 결국 수동으로 삭제해야했다.
• 근데 쿠버네티스의 파드는 파드라는 단위로 컨테이너를 묶어 이 귀찮은 작업들을 대신 해준다.
• 파드는 근데 app을 띄우기 위해 이미지가 필요하다.
• kubectl run nginx --image nginx --image 옵션을 이용해서 nginx 이미지를 불러오는 명령어다. tag를 지정하지 않으면 latest로 자동인식된다.

 

Pod Yaml 기반

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  containers:
  - name: nginx
    image: nginx:latest

• 쿠버네티스는 YAML 파일을 파드, replicas, deployments, service 등을 생성하는 데 사용한다.
• 쿠버네티스 YAML은 항상 4가지의 filed가 있어야한다. 그리고 이 4개의 필드가 위치한 곳이 root 레벨이다.
  • apiVersion
    • apiVersion은 말그대로 쿠버네티스가 개체를 생성함에 있어 사용하는 api 버전이다.

Kind	Version
Pod	v1
Service	v1
ReplicaSet	apps/v1
Deployment	apps/v1

(apiVersion 요약)

• Kind
  • Kind의 경우 만들고자 하는 개체의 유형을 적어주면 된다. 위 예제에서는 Pod 라고 타입을 지정해 주었다.
  • ReplicaSet을 만들고자 한다면 Kind 에 ReplicaSet을 기재해주면 된다.
    주의할 점은 ReplicaSet은 Version도 변경해주어야 한다.
• metadata
  • metadata는 개체의 이름, 레이블과 같은 데이터이다.
  • dict의 형태로 value는 문자열 유형이다.
  • 레이블을 설정하면 나중에 레이블 기반으로 파드를 필터링하는 게 가능하다.
• spec
  • spec은 우리가 생성하려는 개체에 따라 쿠버네티스에게 그 개체와 관련된 추가 정보를 제공하는 곳
  • Pod안에 Container라는 속성을 넣어서 컨테이너를 여러개 또는 단일로 구성할 수 있다.
• kubectl describe pod <pod명> 하면 만들어져있는 pod에 대한 상세 정보를 확인 가능하다.

kubectl describe pod kube-scheduler-kub-a7 -n kube-system
Name:                 kube-scheduler-kub-a7
Namespace:            kube-system
Priority:             2000000000
Priority Class Name:  system-cluster-critical
Node:                 kub-a7/10.16.62.16
Start Time:           Wed, 28 Dec 2022 13:16:25 +0100
Labels:               component=kube-scheduler
                      tier=control-plane
Annotations:          kubernetes.io/config.hash: 2495d4d1888db1561e78ccbc2ff8677c
                      kubernetes.io/config.mirror: 2495d4d1888db1561e78ccbc2ff8677c
                      kubernetes.io/config.seen: 2022-12-25T23:35:24.079223744+01:00
                      kubernetes.io/config.source: file
                      kubernetes.io/psp: system-unrestricted-psp
Status:               Running
IP:                   10.16.62.16
IPs:
  IP:           10.16.62.16
Controlled By:  Node/kub-a7
Containers:
  kube-scheduler:
    Container ID:  containerd://4f91f29659fd641ddfde44687790889a646b5b05de04b3fcb24151f73b3c4c86
    Image:         index.docker.io/rancher/hardened-kubernetes:v1.23.15-rke2r1-build20221208
    Image ID:      docker.io/rancher/hardened-kubernetes@sha256:c9b4b723041f09938d807f633b07d69c125ce40430d3e8c5c5fc8c4e777822e3
    Port:          <none>
    Host Port:     <none>
    Command:
      kube-scheduler
      --permit-port-sharing=true
      --authentication-kubeconfig=/var/lib/rancher/rke2/server/cred/scheduler.kubeconfig
      --authorization-kubeconfig=/var/lib/rancher/rke2/server/cred/scheduler.kubeconfig
      --bind-address=0.0.0.0
      --config=/var/lib/rancher/rke2/server/sched/scheduler-policy-config.yaml
      --kubeconfig=/var/lib/rancher/rke2/server/cred/scheduler.kubeconfig
      --profiling=false
      --secure-port=10259
    State:          Running
      Started:      Wed, 28 Dec 2022 13:16:25 +0100
    Last State:     Terminated
      Reason:       Unknown
      Exit Code:    255
      Started:      Wed, 28 Dec 2022 12:45:25 +0100
      Finished:     Wed, 28 Dec 2022 13:16:23 +0100
    Ready:          True
    Restart Count:  6
    Requests:
      cpu:     100m
    Liveness:  http-get https://localhost:10259/healthz delay=15s timeout=15s period=10s #success=1 #failure=8
    Environment:
      FILE_HASH:  1275e65e5d353561e3baaaf6e6926e1bb5cf859fc91cfa40098cc9acc66b59ca
      NO_PROXY:   .svc,.cluster.local,10.42.0.0/16,xxx::/96,10.43.0.0/16,xx::/112
      POD_HASH:   dc84091d5df12b208576ea0ae27f5a54
    Mounts:
      /var/lib/rancher/rke2/server/cred/scheduler.kubeconfig from file1 (ro)
      /var/lib/rancher/rke2/server/db/etcd/name from file0 (ro)
      /var/lib/rancher/rke2/server/sched/scheduler-policy-config.yaml from file2 (ro)
      /var/lib/rancher/rke2/server/tls/client-scheduler.crt from file3 (ro)
      /var/lib/rancher/rke2/server/tls/client-scheduler.key from file4 (ro)
      /var/lib/rancher/rke2/server/tls/server-ca.crt from file5 (ro)
Conditions:
  Type              Status
  Initialized       True 
  Ready             True 
  ContainersReady   True 
  PodScheduled      True 
Volumes:
  file0:
    Type:          HostPath (bare host directory volume)
    Path:          /var/lib/rancher/rke2/server/db/etcd/name
    HostPathType:  File
  file1:
    Type:          HostPath (bare host directory volume)
    Path:          /var/lib/rancher/rke2/server/cred/scheduler.kubeconfig
    HostPathType:  File
  file2:
    Type:          HostPath (bare host directory volume)
    Path:          /var/lib/rancher/rke2/server/sched/scheduler-policy-config.yaml
    HostPathType:  File
  file3:
    Type:          HostPath (bare host directory volume)
    Path:          /var/lib/rancher/rke2/server/tls/client-scheduler.crt
    HostPathType:  File
  file4:
    Type:          HostPath (bare host directory volume)
    Path:          /var/lib/rancher/rke2/server/tls/client-scheduler.key
    HostPathType:  File
  file5:
    Type:          HostPath (bare host directory volume)
    Path:          /var/lib/rancher/rke2/server/tls/server-ca.crt
    HostPathType:  File
QoS Class:         Burstable
Node-Selectors:    <none>
Tolerations:       :NoExecute op=Exists
Events:
  Type    Reason          Age    From     Message
  ----    ------          ----   ----     -------
  Normal  SandboxChanged  34m    kubelet  Pod sandbox changed, it will be killed and re-created.
  Normal  Pulled          34m    kubelet  Container image "index.docker.io/rancher/hardened-kubernetes:v1.24.8-rke2r1-build20221110" already present on machine
  Normal  Created         34m    kubelet  Created container kube-scheduler
  Normal  Started         34m    kubelet  Started container kube-scheduler
  Normal  SandboxChanged  3m23s  kubelet  Pod sandbox changed, it will be killed and re-created.
  Normal  Pulled          3m23s  kubelet  Container image "index.docker.io/rancher/hardened-kubernetes:v1.24.8-rke2r1-build20221110" already present on machine
  Normal  Created         3m23s  kubelet  Created container kube-scheduler
  Normal  Started         3m23s  kubelet  Started container kube-scheduler

• kubectl create 나 apply 로 yaml 파일을 적용할 수 있다.
• yaml 파일로 생성할 때에는 kubectl apply -f pod.yaml f 옵션을 사용해 파일을 지정해준다.

 

Deployments

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14.2
        ports:
        - containerPort: 80

• 웹 서버 한대가 아니라 여러 개의 웹 서버가 실행되어야 할 때가 있다.
• Docker Registry에 새로운 App 이미지가 올라가게 되고 App을 신규 버전으로 배포하게 되면 인스턴스를 업그레이드 해야 된다. 인스턴스를 업그레이드할 때 한꺼번에 업그레이드 하게되면 서비스 장애가 발생하게 됨.
• 그래서 보통 하나씩 앱이 업그레이드 되는 롤링 업데이트를 하게 된다.
• 업그레이드 중 오류가 발생해 최근 업그레이드를 취소해야한다면 최근 업그레이드를 되돌리는 방법이 좋겠다.
• 또한 앱 버전을 업그레이드 하거나 환경을 조정하거나 리소스 할당도 수정할 수 있고, 명령이 실행된 직후 변경이 적용되는 것을 방지하기 위해 환경을 일시 중지해 모든 변화를 다시 시작하기도 한다.(롤아웃)
• 위 모든 기능을 Deployment에서 제공한다.
• Deployment를 이용해 단일 인스턴스를 배포하는 파드의 경우도 있고 ReplicaSet을 이용해 다수의 파드를 배포하는 경우도 있다.

 

Service

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

• 서비스는 앱 안밖의 다양한 구성요소 간의 통신을 가능하게 한다.
• 쿠버네티스 서비스는 애플리케이션을 다른 애플리케이션 또는 사용자와 연결하는 걸 도와준다.
• 가령 애플리케이션은 보통 3-Tier 라고 웹 계층, 백 엔드 계층, DB 계층으로 나누어 설계하는 데 이 계층 간 연결을 가능하게하는 것이 서비스이다.
• 서비스는 세 개의 타입을 가지고 있다.
  • NodePort :
    • 서비스가 내부 포트를 노드의 포트에 액세스할수 있게 함
    • Pod에 접근할 수 있는 포트를 Cluster의 모든 Node에 동일하게 개방해 외부에서 Pod로 접근할 수 있게함.
    • http://<노드IP>:<nodeport의 port번호> 이런식으로 접근하게 된다.
  • ClusterIP :
    • 서비스는 클러스터 안에서 가상의 IP를 만들어 다른 서비스간의 통신을 가능하게 한다.
  • LoadBalancer :
    • 클라우드 제공자에 있는 로드 밸런서를 프로비저닝하는 것

 

NodePort

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  type: NodePort
  selector:
    app.kubernetes.io/name: MyApp
  ports:
      # 기본적으로 그리고 편의상 `targetPort` 는 `port` 필드와 동일한 값으로 설정된다.
    - port: 80
      targetPort: 80
      # 선택적 필드
      # 기본적으로 그리고 편의상 쿠버네티스 컨트롤 플레인은 포트 범위에서 할당한다(기본값: 30000-32767)
      nodePort: 30007

• selector가 있으면 동일 label이 있는 pod를 서비스가 대상으로 할 수 있다.
• 노드포트의 로드밸런싱 알고리즘은 무작위

 

ClusterIP

apiVersion: v1
kind: Service
metadata:
  labels:
    k8s-app: kube-dns
    kubernetes.io/cluster-service: "true"
    kubernetes.io/name: CoreDNS
  name: kube-dns
  namespace: kube-system
spec:
  clusterIP: 10.96.0.10
  ports:
  - name: dns
    port: 53
    protocol: UDP
    targetPort: 53
  - name: dns-tcp
    port: 53
    protocol: TCP
    targetPort: 53
  selector:
    k8s-app: kube-dns
  type: ClusterIP

• Pod는 모두 할당된 IP 주소가 있다. 하지만 Pod가 삭제 되었다가 다시 새 파드로 만들어 지면 이 IP는 동적으로 변경된다.
• 앱 간의 내부 통신에 이 IP 주소만을 의존할 수 없는 이유다.
• ClusterIP는 클러스터 내부에서 IP와 그에 할당된 이름을 갖고 다른 Pod가 접속할 때 해당 이름을 사용하게 된다.

 

LoadBalancer

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app.kubernetes.io/name: MyApp
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376
  clusterIP: 10.0.171.239
  type: LoadBalancer
status:
  loadBalancer:
    ingress:
    - ip: 192.0.2.127

• 클라이언트가 단일 URL을 이용해 웹서버같은 응용 프로그램에 접속하려면 몇 가지 방법이 있다.
• 첫째는 적절한 부하 분산기 애플리케이션을 구성해(HAProxy, Nginx 와 같은) 기본 노드로 트래픽을 라우팅하는 게 있다. 근데 이 방법은 모든 외부 트래픽을 부하 분산 설정하고 유지하고 관리하는 공수가 들어간다.
• 둘째는 클라우드에서 제공되는 플랫폼 자체 부하 분산 장치와 통합하는 것
• AWS와 같은 클라우드에서 LoadBalancer를 구성하게 되면 외부의 트래픽을 서비스를 통해 내부 app으로 전달할 수 있는 역할

 

[참조] :

https://www.udemy.com/course/certified-kubernetes-administrator-with-practice-tests/

kube-proxy 3가지 모드
Service yaml 예제