CKA를 준비하며..

PODs

• containers are encapsulated in pods
• pod == smallest obj in kube
• 유저가 늘어나면 pod에 container를 추가하는게 아니라 container가 든 pod를 추가하는 방식이다. 그러다 node가 다 차면 새로운 node를 추가하고, 그 node 안에는 container가 든 pod 추가한다.
• single pod도 multi container를 가질 수 있다. 그러나 일반적이진 않다. → 같은 두 컨테이너를 띄우지는 않고, 하나는 메인 컨테이너, 하나는 헬퍼 컨테이너식으로. 이 경우 서로 스토리지 공유, 네트워크 공유가 쉽다.

kubectl get pods
kubectl run nginx --image={imgname}
kubectl describe pod {podname}
kubectl delete pod {podname}
kubectl create -f {yamlfile}
kubectl run redis --image=redis123 --dry-run=client -o yaml > redis-definition.yaml
kubectl apply -f redis-definition.yaml

ReplicaSets

• Replication Controller는 multiple pod instance를 유지하도록 도와준다. pod가 하나여도 가능하다. HA를 위한 것.
• Replication Controller는 여러 node에 걸쳐 pod를 관리할 수 있다.
• Replica Set가 컨트롤러를 대체해가는 중이다. 얘만 쓸거다.
• 얘도 마찬가지로 같은 형식의 yaml으로 생성한다.
• spec 내 template가 pod를 설명한다. (얘가 replicaCon이 ha 할 pod를 정의 → 위 yaml을 그대로 갖다 써도 됨. (apiVersion과 kind만 빼고)) → 즉 nested 구조인 것이다.
• Replicaset와의 차이는 selector이다. 이는 template로 생성되지 않은, 다른 pod까지 관리할 수 있는 기능이다. → 이게 controller와 가장 중요한 차이이다.
• 근데 이미 생성된 pod 관리만 할 때는 template이 왜 필요한가 → 추후에 하나가 fail하면 그때 Pod 다시 띄우기 위해 필요하다.

kubectl get replicasets
kubectl get rs
kubectl create -f ./replicaset-definition-1.yaml
kubectl apply -f /root/replicaset-definition-2.yaml
kubectl delete rs replicaset-1
replicaset의 selector의 matchlabels의 tier와 template - label - tier가 일치해야한다.

Deployment

• replicaset 내에 여러 pod들이 관리되고, 그 pod 안에 보통 1개의 컨테이너가 뜬다.
• deployment 내에 여러 replicaset이 있다. → rolling update와 같은 다양한 배포 전략이 가능하다.
• Deployement만 생성해도 자동으로 replicaset이 생성된다. kind만 다르고 대부분 내용은 비슷.

kubectl get all

• 팁! Yaml 파일을 직접 건드리는건 시험에서 별로 효율적이지 않은 방법이다.

Create an NGINX Pod

kubectl run nginx --image=nginx

Generate POD Manifest YAML file (-o yaml). Don't create it(--dry-run)

kubectl run nginx --image=nginx --dry-run=client -o yaml

Create a deployment

kubectl create deployment --image=nginx nginx

Generate Deployment YAML file (-o yaml). Don't create it(--dry-run)

kubectl create deployment --image=nginx nginx --dry-run=client -o yaml

Generate Deployment YAML file (-o yaml). Don't create it(--dry-run) with 4 Replicas (--replicas=4)

kubectl create deployment --image=nginx nginx --dry-run=client -o yaml > nginx-deployment.yaml

Save it to a file, make necessary changes to the file (for example, adding more replicas) and then create the deployment.

kubectl create -f nginx-deployment.yaml

OR

In k8s version 1.19+, we can specify the --replicas option to create a deployment with 4 replicas.

kubectl create deployment --image=nginx nginx --replicas=4 --dry-run=client -o yaml > nginx-deployment.yaml

Services

• 서비스는 애플리케이션간 연결. pod간 연결을 위한 것이다.
• 우리 로컬과 pod의 네트워크가 다르면?

1. ssh나 http로 접속한다. 이런 방법 말고, 직접 접근은??
2. service를 사용한다. port forwarding해준다. NodePort service라 한다.

• 서비스는 NodePort / ClusterIP / LoadBalancer 세 종류가 있다.

NodePort

• 80으로 들어간다고 하자. 서비스쪽의 포트는 port, pod쪽 포트는 targetPort
• Service도 ip를 갖는다. 얘를 ClusterIP라 함
• Node Port는 아예 외부에서 접속해 들어오는 포트

type: NodePort
ports:
- targetPort: 80  
    port: 80
    nodePort: 30008

• 주의! 여기서 필수는 port만이다. targetport는 디폴트 port와 동일, nodeport는 디폴트로 30000-32767
• kubectl get services
• Pod가 여러개면? selector와 label로 명시만 해주면 알아서 여러개 엔드포인트로 연결 해주고, lb는 알아서 랜덤하게 해준다.
• node가 여러개면? 신경쓸 필요 없다.

Cluster IP

• Pod 층 간 연결이 필요! 프론트 백 db pod들이 각각 떠있을테니까
• pod를 그룹으로 묶고 한번에 access 용 ip를 제공한다. → MSA가 쉽다.

type: ClusterIP
ports:
- targetPort: 80
    port: 80
selector:
	app: myapp
	type: back-end

• 이렇게 하면 저 조건의 pod이 한번에 묶여서 ip를 할당받는다

LB

• 외부 유저한테 연결하는 용도의 node port. pod 간 연결 인터페이스를 제공하는 cluster ip.
• 여러 엔드포인트가 있겠지. 그런데 하나의 단일 엔드포인트가 필요함.
• 이거 lb도 해주는 기능이 있음. type을 LoadBalancer로. (aws gcp azure 가능. 안되는 플랫폼에서는 사실상 nodeport와 동일)

Namespaces

• 이름으로 각 리소스를 분리하는 역할. Prod에서 사용 고려할만 하다. 안전을 위해 사용한다.
  kubectl create -f pod-definition.yml --namespace=dev 이렇게 실행해줘도 되고 yaml파일 내에 metatadata 아래로 옮겨줘도 된다.

kubectl create namespace dev / kubectl create -f namespace-dev.yml
kubectl get pods - -all namespaces
kubectl config set-context $(kubectl config current-context) - -namespace=dev

Imperative vs Declarative

• imperative: 어떻게 할지를 묘사. ↔ Declative: 무엇을 할지를 선언

• imperative : run, create, expose, edit … yaml file 건들지 않고 직접 선언해주기

  • 쉽고 빠르지만 트래킹 어렵고 기능 제한이 있는 편

• edit은 k8s 메모리 상의 definition 파일을 수정할 뿐, 로컬은 그대로다. 로컬에 반영하려면
  kubectl replace -f nginx.yaml
kubectl replace —force -f nginx.yaml

• declative
  kubectl apply -f nginx.yaml

  • update나 생성 모두 알아서 해준다 → intelligent enough!

• tip

  • --dry-run=client → test용
  • -o yaml → yaml 형식으로 output 생성

Kubectl apply command

• 기존은 local file - k8s live obj conf 이중체제였다.
• apply는 그 사이에 last applied conf를 추가하여 sync를 맞춘다. 이는 remove 내역을 트래킹하기 위함이다.
• last applied conf는 live obj conf 내에 annotation으로 저장된다.