02. K8s Objects

Pod

---

• 가장 작은 배포 단위
• 전체 클러스터에서 고유한 IP 할당
• 1~N 개의 Container 를 포함
  • Pods usually have a one-to-one relationship with containers running the app.
  • A single pod can have multiple containers, not the same kind of container but helper containers instead.
• host 폴더 공유, localhost 네트워크 공유
  • This means the app container and the helper container can communicate through localhost.

How to deploy pods

kubectl run nginx --image nginx
kubectl get pods

• The first line of command will pull the image from wherever K8s is configured to pull the image from such as public Docker Hub or private registries.

YAML in K8s

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  labels:
    app: myapp
    type: front-end
spec:
  containers:
    - name: nginx-container
      image: nginx

• K8s uses YAML files as inputs for creating objects and all objects contain 4 top-level fields.
  • apiVersion
    • The version of K8s API that is used for creating the object.
    • e.g. v1, apps/v1, etc
  • kind
    • The type of the object to be created.
    • e.g. Pod, Service, ReplicaSet, Deployment, etc
  • metadata
    • A dictionary for metadata describing the object.
    • e.g. name, labels, etc
  • spec
    • A specification of the object to be created.
    • For the above example, containers section is a list that can be listed with - character.

A pod can be created with the command below:

kubectl run nginx --image=nginx

or using a YAML file:

kubectl create -f pod-definition.yaml
kubectl get pods
kubectl describe pod myapp-pod

kubectl run redis --image=redis --dry-run=client -o yaml > redis.yaml

kubectl 명령어로 template yaml file 을 생성하고 싶은 경우 --dry-run 과 -o yaml 옵션을 통해 yaml file 을 생성할 수 있다.

ReplicaSet

---

• Replication Controller & ReplicaSet is similar but different. The Replication Controller is the older technology that ReplicaSet replaces.
• The ReplicaSet helps to run and maintain the desired number of pods in the K8s cluster by creating and deleting pods based on the configuration. This allows the K8s cluster to achieve high availability.
• It also provides load-balancing & scaling capability by deploying additional pods in existing or additional nodes. This means the ReplicaSet spans across multiple nodes in the cluster.

Creating Replication Controller with YAML

apiVersion: v1
kind: ReplicationController
metadata:
  name: myapp-rc
  labels:
    app: myapp
    type: front-end
spec:
  template:
    metadata:
      name: myapp-pod
      labels:
        app: myapp
        type: front-end
    spec:
      containers:
      - name: nginx-container
        image: nginx
  replicas: 3

• template
  • A template of the pod definition.
• replicas
  • Number of replicas of the template.

Then run the below commands to create and see the objects created.

kubectl create -f rc-definition.yaml
kubectl get replicationcontroller
kubectl get pods

Creating ReplicaSet with YAML

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: myapp-replicaset
  labels:
    app: myapp
    type: front-end
spec:
  template:
    metadata:
      name: myapp-pod
      labels:
        app: myapp
        type: front-end
    spec:
      containers:
      - name: nginx-container
        image: nginx
  replicas: 3
  selector:
    matchLabels:
      type: front-end

• template
  • A template of the pod definition.
• replicas
  • Number of replicas of the template.
• selector
  • It helps identify pods that fall under it so that it can monitor the selected pods and maintain the number of replicas in the cluster.

Then run the below commands to create and see the objects created.

kubectl create -f replicaset-definition.yaml
kubectl get replicaset
kubectl get pods

To scale the number of replicas by file:

kubectl replace -f replicaset-definition.yaml

To scale the number of replicas by command:

kubectl scale --replicas=6 -f replicaset-definition.yaml

or

kubectl scale --replicas=6 replicaset myapp-replicaset

• Note these two commands will not change the definition file.

Deployment

---

• 내부적으로 ReplicaSet 을 이용하여 배포 버전을 관리
• The Deployment provides the capability of upgrading underlying instances seamlessly using rolling updates, undo changes, pauses, and resume changes as required.

Creating Deployment with YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp-replicaset
  labels:
    app: myapp
    type: front-end
spec:
  template:
    metadata:
      name: myapp-pod
      labels:
        app: myapp
        type: front-end
    spec:
      containers:
      - name: nginx-container
        image: nginx
  replicas: 3
  selector:
    matchLabels:
      type: front-end

• All contents of the Deployment are exactly similar to the ReplicaSet definition file.

Run the below commands to create and find the objects created:

kubectl create -f deployment-definition.yaml
kubectl get deployments
kubectl get replicaset
kubectl get pods

or

kubectl get all

Service

---

NodePort

apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  type: NodePort
  ports:
   - targetPort: 80
   - port: 80
   - nodePort: 30008
  selector:
    app: myapp
    type: front-end

• Node(host) 에 노출되어 외부에서 접근 가능한 서비스
• 모든 Node 에 동일한 포트로 생성
• targetPort 는 target pod 의 port 를 지정, 지정하지 않을 경우 port 와 같은 값을 가짐
• port 는 Service Object 의 port 를 지정 (required)
• nodePort 는 30,000 ~ 32,767 까지의 범위 안에 속해야 하며 지정하지 않을 경우 자동으로 할당됨
• selector 를 통해 target pod 를 지정
• 하나의 Node 에 같은 종류의 Pod 가 여러개 있을 경우 Service 가 알아서 selector 에 해당하는 Pod 를 찾고 부하를 분산하여 각각 Pod 에 Random 하게 보내줌.
• 여러 Node 에 Pod 가 배포되어 있을 경우에도 Service 는 모든 Node 에 걸쳐 적용되어 아무 Node 에 요청을 보내도 알아서 아무 Node 에 배포된 Pod 에 트래픽을 보냄.

ClusterIP

apiVersion: v1
kind: Service
metadata:
  name: back-end
spec:
  type: ClusterIP
  ports:
   - targetPort: 80
   - port: 80
  selector:
    app: myapp
    type: back-end

• 클러스터 내부에서 사용하는 프록시
• Pod 은 동적이지만 서비스는 고유 IP 를 가짐
• 클러스터 내부에서 서비스 연결은 DNS 를 이용
• 가령 3-tier-architecture 에서 backend app 에 요청을 보내고 싶을 때 backend 를 담당하는 여러 Pod 가 cluster 전체에 퍼져있으니 ClusterIP 를 통해 원하는 layer 를 지정

kubectl run httpd --image=httpd --port=80 --expose

• kubectl run 으로 Pod 를 생성할 때 —expose 옵션을 주면 Pod 에 연결되는 ClusterIP 를 자동으로 생성해준다. ClusterIP 와 연결되어야 하기 때문에 —port 옵션이 필수적으로 포함되어야 한다.

LoadBalancer

apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  type: LoadBalancer
  ports:
   - targetPort: 80
   - port: 80
   - nodePort: 30008

• 하나의 IP 주소를 외부에 노출하여 지정된 Pod 에 요청이 도달할 수 있도록 도와줌
• NodePort 대신 AWS, Azure, GCP 등에서 제공하는 Native Load Balancer 로 부하를 분산하여 보내는 역할을 수행함

Namespaces

---

K8s Cluster 를 구축하게되면 기본적으로 Default, kube-system, kube-public Namespace 들이 자동으로 생성된다. 사용자가 생성한 Pod, Deployment, Service 등 K8s Object 들은 기본적으로 Default Namespace 에 속하게 된다.

kubectl get pods --namespace=kube-system

kube-system Namespace 의 경우, coredns, etcd-master, kube-apiserver-master, kube-controller-manager-master 등 K8s 의 기본적인 Component 들을 확인할 수 있다.

kubectl create -f pod-definition.yml --namespace=dev

K8s Object 를 특정 Namespace 에 배포하고 싶을 경우엔 옵션으로 namespace 를 지정해주거나,

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  namespace: dev
  labels:
    app: myapp
    type: front-end
spec:
  containers:
    - name: nginx-container
      image: nginx

위 처럼 metadata 필드에 namespace 를 추가해주면된다.

apiVersion: v1
kind: Namespace
metadata:
  name: dev

Namespace 를 생성할 땐 위처럼 Namespace yaml 을 생성한 뒤,

kubectl create -f namespace-dev.yml

위 명령어로 생성하거나,

kubectl create namespace dev

yaml 파일 없이 명령어로 생성할 수 있다.

kubectl config set-context $(kubectl config current-context) --namespace=dev

위 명령어를 통해 cli 작업 위치를 특정 Namespace 로 이동시킬 수도 있다.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: compute-quota
  namespace: dev
spec:
  hard:
    pods: "10"
    requests.cpu: "4"
    requests.memory: 5Gi
    limits.cpu: "10"
    limits.memory: 10Gi

특정 Namespace 에 하드웨어 리소스를 할당할 때엔 ResourceQuota yaml 을 생성한 뒤,

kubectl create -f compute-quota.yml

생성하여 자원을 할당해줄 수 있다.

Imperative vs Declarative

---

IaC 에선 명령형과 선언형 방식으로 인프라를 구축할 수 있는데,

kubectl run --image=nginx nginx
kubectl create deployment --image=nginx nginx
kubectl expose deployment nginx --port 80

위 같은 명령어들을 통해 Object 를 생성하고,

kubectl edit deployment nginx
kubectl scale deployment nginx --replicas=5
kubectl set image deployment nginx nginx=nginx:1.18

생성된 Object 를 수정할 수 있다. 이는 명령형 방식으로 K8s 를 구축하는 방법이다.

kubectl create -f nginx.yaml
kubectl edit deployment nginx

K8s configuration file 을 통해 Object 를 생성한 경우 선언형 방식으로 구축했다고 생각할 수 있지만, edit 명령어를 통해 접근한 file 은 K8s memory 에 동적으로 생성된 yaml 인 것을 확인할 수 있다. 때문에 edit 으로 설정을 바꾼다고 기존에 작성한 nginx.yaml 은 수정되지 않기 때문에 추후에 replace 등을 할 경우 예상하지 못한 변경이 생길 수 있다. 이를 방지하기 위해선 edit 대신 configuration file 자체를 변경한 후 replace 를 실행하는 것이 바람직하다.

kubectl apply -f nginx.yaml

K8s 는 apply 를 통해 선언형 방식으로 Object 를 제어할 수 있다. apply 는 이미 만들어진 Object 를 파악하며 부분적으로 설정이 수정된 경우 해당 부분만 적용하는 기능 역시 지원한다.

# Live object configuration
apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  annotations:
    kubectl.kubernetes.io/last-applied-configuration: {"apiVersion": "v1", ...}
  labels:
    app: myapp
    type: front-end
spec:
  containers:
  - name: nginx-container
    image: nginx
status:
  conditions:
  - lastProbeTime: null
    ...

kubectl apply 를 실행하면 K8s 는 사용자가 작성한 yaml file 과 K8s memory 에 저장된 Live object configuration 과 kubectl.kubernetes.io/last-applied-configuration 필드를 비교하여 변경된 사항만 부분적으로 확인하고 적용이 가능하다.

Ingress

---

• 도메인 또는 경로별 라우팅
  • Nginx, HAProxy, ALB, …

References

---

• Udemy - Certified Kubernetes Administrator (CKA) with Practice Tests