[CKA] Core Concepts

◼ Cluster Architecture

https://kubernetes.io/docs/concepts/overview/components/

• Master/Worker Nodes
  • Master Node: Control Plane 컴포넌트가 위치한 노드로 클러스터를 관리하는 노드
  • Worker Node: application을 서비스하는 노드
• Control Plane
  • ETCD: key, value 로 구성되어 있는 클러스터의 database
  • Schedule: Container가 적절한 node에 배치될 수 있게 해 준다(container 및 noded의 크기, policy 등을 고려)
  • Controller manager: 상황에 따라 새로운 container를 만들거나 삭제를 담당
    • node controller: node 상태 관리(작동하는지 안하는지 등)
    • Replication controller: 파드 갯수 관리
    • 등등 여러가지가 있다
  • Kube API server: cluster안에서 ochesteration을 담당한다.(모니터링, 컴포넌트 간 소통 등)
• Kubelet: node에 위치한 agent로 kube api와 상호작용한다. node에 pod 등 생성 및 삭제하고 node의 상태를 나타낸다.
• Kube-Proxy: 각각의 node에 위치하여 node간 network 연결을 가능하게 해 준다

◼ ETCD

Distributed reliable key-value store that is Simple, Secure & Fast

• key-value database
• defaulrt port: 2379

설치 및 실행

$ apt update
$ apt install etcd-client

• TLS 설정이 되어있다면 --cacert, --cert, --key 정보를 명시해줘야 한다.
• etcd pod를 describe 하여 사용해야 하는 파일 확인이 필요하다.
• 환경변수 설정으로 생략해줄 수 있다.
• ETCDCTL_API=3을 명시해주지 않으면 버전 2를 사용하게 된다.
  • etcdctl 3.4 버전부터는 따로 명시해주지 않아도 된다.

◼ Kube-API server

The API server is the front end for the Kubernetes control plane

pod 요청 수행 과정

https://blog.netsil.com/kubernetes-tutorial-an-api-perspective-on-how-kubernetes-works-5fd30d1010ff

1. Authenticate User
   • 요청이 수행될 수 있는지 인증 확인
2. Validate Request
   • 유요한 요청인지 검사
3. Retreive data
   • etcd에 관련 정보가 있는지 확인
4. Update ETCD
   • pod object 생성 및 etcd 업데이트
5. Scheduler
   • scheduler는 api 서버를 watch 하고 있기 때문에 새로운 pod 확인
   • 배치시킬 node 확인
6. Kubelet
   • api는 update 된 정보를 kubelet에 전달
   • kubelet은 docker runtime에 container 생성 지시
   • api 서버에 상태 업데이트

◼ kube controller manager

Control plane component that runs controller processes.

• 크게 두 가지 역할 수행
  • 상태 확인(Watch Status)
  • 문제 처방(Remediate Situation)

https://github.com/kodekloudhub/certified-kubernetes-administrator-course/tree/master/docs

• 각각의 controller는 논리 적인 프로세스로 분리되어 있지만 복잡도를 줄이기 위해 하나의 바이너리로 컴파일되어 단일 프로세스에서 실행된다.
  • Node Controller: 노드 상태를 확인한다.
    • --node-monitor-period (Default: 5s): 5초 간격으로 health check
    • --node-monitor-grace-period (Default: 40s): node에 문제가 생겼을 때 unhealthy 상태 유지 시간
    • --pod-eviction-timeout (Default:5m): pod 추출 시간
  • Replication Controller
    • replicaSet의 상태를 모니터링하고 명시한 pod 갯 수 유지

◼ Scheduler

Control plane component that watches for newly created Pods with no assigned node, and selects a node for them to run on.

• pod가 어떤 노드로 갈 것인지 결정하는 역할
  • 실제 node에 pod를 생성하는 것은 kubelet이 수행
• 기본적인 스케줄 방법(i.e. Pod가 CPU 10이라는 크기의 자원이 필요로 한다면)
  1. Filter Node: 할당이 가능한 node를 찾는다
  2. Rank Nodes: 더 여유 있는 node를 찾는다.
  

◼ Kubelet

It makes sure that containers are running in a Pod

• sceduler의 지시에 따라 container runtime에 container 생성 및 제거 지시
• 일정 간격으로 컨테이너 상태 모니터링(PodSpecs대로 되어 있는지 살아있는지 등)하여 api에 전달
• kubelet은 k8s와 별도로 만든 container는 관리하지 않는다.
• kubeadm은 kublet을 deploy 하지 않기 때문에 별도로 만들어줘야 한다.

◼ Kube-Proxy

kube-proxy is a network proxy that runs on each node in your cluster

https://github.com/kodekloudhub/certified-kubernetes-administrator-course/tree/master/docs

• node 간의 network규칙을 관리한다.
  • Pod들의 cluster안에서의 통신과 cluster 밖과의 통신을 포함한다.
• k8s의 service를 구현하기 위해 존재
  • cluster 내에 생성되는 가상 네트워크
  • service에도 ip가 할당되며 service ip로 요청이 오면 pod로 forward 된다.(iptable 등을 사용한다)
• kubeadm은 daemonset으로 각각의 node에 하나의 proxy를 생성한다.

◼ Pods

Pods are the smallest deployable units of computing that you can create and manage in Kubernetes.

https://github.com/kodekloudhub/certified-kubernetes-administrator-course/tree/master/docs

• k8s에서 배포 가능한 가장 작은 단위
  • container하나씩 배포하지 않고 container 묶음 단위
  • pod라는 object로 캡슐화
• storage, network 자원과 어떻게 container를 실행시켜야 되는지 정의를 공유한다.
• shared storage and network resources, and a specification for how to run the containers.

◼ ReplicaSets

A ReplicaSet's purpose is to maintain a stable set of replica Pods running at any given time.

Replication Controller

• 고가용성(정의된 Pod 개수를 유지해준다)
• Load Balancing & auto scaling(여러 개의 Pod를 만들어 load가 분산될 수 있다)

Replication Controller | ReplicaSets

• 같은 목적을 갖고 있다.
• ReplicaSet은 Replica를 만들기 위한 새로운 방법
  
  

ReplicationController	ReplicaSet
apiVersion: v1 kind: ReplicationController metadata:   name: nginx spec:   replicas: 3   selector:     app: nginx   template:     metadata:       name: nginx       labels:         app: nginx     spec:       containers:       - name: nginx         image: nginx         ports:         - containerPort: 80	apiVersion: apps/v1 kind: ReplicaSet metadata:   name: frontend   labels:     app: guestbook     tier: frontend spec:   # modify replicas according to your case   replicas: 3   selector:     matchLabels:       tier: frontend   template:     metadata:       labels:         tier: frontend     spec:       containers:       - name: php-redis         image: gcr.io/google_samples/gb-frontend:v3

• 차이점: ReplicSet은 selector가 있다
  • selector로 replica를 지정할 pod를 지정할 수 있다
  • ReplicaSet이 만들지 않은 Pod를 관리할 수 있게 된다.
  • 어떤 Pod를 지정할지는 label을 사용한다.

◼ Deployments

A Deployment provides declarative updates for Pods and ReplicaSets.

https://github.com/kodekloudhub/certified-kubernetes-administrator-course/tree/master/docs

• Production 환경에 application을 원활하게 배포가 되게 도와준다
  • ReplicaSet의 상위 Object
  • ReplicaSet을 rollout
  • 새로운 Pod 상태 정의
  • 이전 배포 버전으로 회귀
• ReplicaSet의 상위 Object

◼ Namespaces

namespaces provides a mechanism for isolating groups of resources within a single cluster

https://github.com/kodekloudhub/certified-kubernetes-administrator-course/tree/master/docs

• 논리적으로 cluster를 구분
• 많은 사람들이 다양한 팀 혹은 프로젝트로 구분이 필요할 때 사용
• namespace안에서 resource이름은 유일해야 하지만 전체 namespace에서도 그럴 필요 없다.
• resource quota를 사용하여 다수의 사용자 간에 cluser 리소스를 제한할 수 있다.

  apiVersion: v1
  kind: List
  items:
  - apiVersion: v1
    kind: ResourceQuota
    metadata:
      name: pods-high
    spec:
      hard:
        cpu: "1000"
        memory: 200Gi
        pods: "10"
      scopeSelector:
        matchExpressions:
        - operator : In
          scopeName: PriorityClass
          values: ["high"]

• 작은 리소스 간 차이를 구분하기 위해 namespace 사용은 불필요하다
  • 예를들어 버전 같은 경우는 label로 구분시켜주자
• 기본 namespace
  • default: namespace가 없는 object를 위한 기본 namespace
  • kube-system: 쿠버네티스 시스템에서 생성한 오브젝트를 위한 namespace
  • kube-public: 모든 사용자가 읽기 권한으로 접근할 수 있는 namespace로 주로 공개적으로 드러나서 읽을 수 있는 리소스를 위해 예약되어 있다.
  • kube-node-lease: 각 노드의 Lease 오브젝트를 담고 있는 namespace

DNS

dns로 다른 namespace에 있는 자원에 접근 가능하다

• 같은 namespace 경우: 리소스 dns로만 접근 가능
  • mysql.connect('db-service')
• 다른 namespace 경우: 특정 포맷 사용 <service name>.<namespace>.<service>.<domain>
  • mysql.connect('db-service.dev.svc.cluseter.local')

Command

• 현재 context namespace 변경(default에서 dev)
  • kubectl config set-context $(kubectl config current-context) --namespace=dev

◼ Services

An abstract way to expose an application running on a set of Pods as a network service.

• service는 application을 expose 시켜준다. 
  • end user 혹은 cluster안에서 application끼리 혹은 외부 자원과 연결 등
  • micro service에서 커플링을 줄여준다.

NodePort

• Node IP의 특정 port를 노출시켜주는 서비스
• pod가 여러 개일 경우 random 하게 연결시켜준다.
• selector로 pod를 명시 안 하면 따로 Endpoint 리소스를 만들어줘야 한다.

ClusterIP

• cluster 내부에 노출되는 service로 cluster안에서만 접근이 가능하다.
• service의 default 타입
• cluster안에서 application들을 그룹화시켜주는 데 사용된다. 
• service 끼리 통신을 가능하게 해 준다. (mibro service)

서비스를 클러스터-내부 IP에 노출시킨다. 이 값을 선택하면 클러스터 내에서만 서비스에 도달할 수 있다. 이것은 ServiceTypes의 기본 값이다

Load Balancer

• AWS의 ELB 같은 cloud provider의 load balancer를 사용하여 외부에 노 출사 켜주는 서비스
• load balancer가 route 하는 NodePort 및 ClusterIP는 자동으로 생성된다.
• 위와 같이 voting app이 있을 때 하나의 url로 여러 가지 service에 접근할 수 있게 해 준다.
  • voting service와 result service에 접근하게 해주는 하나의 service라고 할 수 있다.

---

Reference

• ETCD
  • https://lzone.de/cheat-sheet/etcd
  • How to use etcdctl without supplying certificates
  • Kubernetes 운영을 위한 etcd 기본 동작 원리의 이해
• service
  • https://da-nika.tistory.com/254
  • https://lascrea.tistory.com/202