K8s) Kubernetes objects

Object

• 선언적으로 추구하는 상태를 기술해둔 것
• 추구하는 상태와 현재 상태가 맞지 않으면 이를 맞추려고 함
• edit 명령어를 통해 추구하는 상태를 변경할 수 있음(수정 시 즉시 이를 반영하려 하기 시작)

 

쿠버네티스 기본 오브젝트

• 파드, 서비스(노드포트, 로드밸런서 형태)
• 네임스페이스
• 볼륨(영속성 - 데이터 저장에 사용됨)
  • NFS(Network File System) Volume을 생성하여 파드에 이를 마운트하는 경우

 

YAML(생성 및 수정)

• Top level property: apiVersion, kind, metadata, spec
• 오브젝트 생성 테스트 등에 사용할 수 있는 옵션
  • 오브젝트를 실제로 생성하지는 않지만, 오브젝트 설정(manifest) 파일을 생성하는 경우 등
  • --dry-run=client: 명령을 실행하되, 실제로 동작하지는 않게 하기 위해 붙이는 옵션
  • -o [file-type]: 결과를 yaml, json 등의 파일 타입으로 생성

  kubectl create pod custom-pod --dry-run=client -o yaml > custom-pod-definition.yaml
  

• 생성: kubectl create -f definition.yaml or kubectl apply -f definition.yaml
• 수정(replace)
  • 기존 객체에 변경 사항 적용(default)
  • kubectl replace -f definition.yaml
  • 객체 삭제 후 다시 생성하는 경우(—-force)
  • kubectl replace --force -f definition.yaml

Pod

apiVersion: v1
kind: Pod
metadata:
  name: redis
spec: 
  containers:
  - name: redis-image
    image: redis123
    ports:
    - containerPort: 8080
		command: ['sleep 1000'] # command:Array
# nodeName: not essential field
  nodeName: marketing
# scheduler: not essential field
	schedulerName: custom-scheduler

• kind의 값은 대소문자 구분함에 유의
• 컨테이너 목록은 -로 구분하는 것에 유의
• spec.containers의 컨테이너 요소에 name 없이 image만 줬더니 오류 발생
• Error - "Error from server (BadRequest): error when creating “pod-definition.yaml”: pod in version “v1” cannot be handled as a Pod: no kind “pod” is registered for version “v1” in scheme
• 이미 존재하는 파드의 경우 아래 필드들 외에는 수정할 수 없다. (저장시 거부되며 임시 사본 생성) → 기존 파드를 지우고 생성된 임시 사본을 통해 새 파드를 만들거나, 현재 파드 정보를 .yaml 파일로 저장한 후 기존 파드 삭제 + 새 파드 생성을 할 수 있다.
  • spec.containers[*].image
  • spec.initContainers[*].image
  • spec.activeDeadlineSeconds
  • spec.tolerations

ReplicationController

• RelicationController: 여러 노드에 걸친 쿠버네티스 클러스터 내에서 항상 n개의 특정 파드가 동작할 수 있게 유지시켜줌 - 1개도 마찬가지
• Pod Template: apiVersion, kind를 제외한 모든 내용

apiVersion: v1
kind: RelicationContoller
metadata:
  name: myapp-rc
  labels:
spec:
  template:
		metadata:
		  name: redis
		spec: 
		  containers:
		  - name: redis-image
		    image: redis
	relicas: 3

ReplicaSet

• apiVersion에 유의 - apps/[version](ex. apps/v1)
• spec의 주요 요소: template, replicas, selector(>matchLabels)
  • template: 유지할 파드 템플릿으로, 파드 생성을 위한 yaml 파일 양식에서 apiVersion, kind만 없는 형태
  • replicas: 유지할 파드 수
  • selector: 하위의 matchLabels와 일치되는 라벨을 가진 파드를 관리

apiVersion: apps/v1
kind: ReplicaSet
metadata:
	name:
	labels:
spec:
  replicas: 3
  

• selector를 통해 모니터링하여 Running되는 파드 수를 유지하는 방식

metadata:
  name: myapp-pod
  labels:
    tier: front-end

selector:
  matchLabels:
    tier: front-end

• Scale 방법
  • yaml 파일의 replicas 수를 변경하고, kubectl replace -f =[file name]과 같이 변경사항을 적용시킨다.

  kubectl replace -f replicaset-definition.yaml
  

  • kubectl scale --replicas=[파드 수] -f [file name]
  • scale 명령어 사용시 파일 수정없이 적용할 수 있다.

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

  • kubectl scale --replicas=[파드 수] [타입(=replicaset)] [replicaset name]

  kubectl scale --replicas=6 replicaset myapp-replicaset
  

  • edit 커맨드 사용해 리소스 설정 변경
    • 버전 관리를 위해 직접 수정보다는 새로운 파일을 생성하는 것이 더 좋음

  kubectl edit rs [replicaset name]
  

DemonSet

manifest 필드와 구성이 ReplicaSet이랑 매우 흡사함

apiVersion: app/v1
kind: DemonSet
metadata:
  name:
spec:
  template:
   (생략)
  

Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
	name:
	labels:
spec:
  template: 
  selector: 
    matctLabels: 
      tier: front-end
  replicas: 3

• ReplicaSet과 kind 만 다름
  • apiVersion: app/v1
  • spec의 구성 요소: template, selector, replicas
• Pod와 달리 kubectl edit을 통해 쉽게 편집 가능(변경 사항이 생기면 Deployment 하위의 파드들이 자동으로 생성/삭제)

Service

apiVersion: v1
kind: Service
metadata:
  name: app-service
spec: 
  type: NordPort
  ports: 
  - targetPort: 80
    port: 80
    nodePort: 30060
  selector:
		[key]:[value]

• ports: 배열 형태
  • 필수 필드는 port(targetPort - 파드 포트 - 생략시 port와 같다고 간주하며, nodePort 생략시 30,000 ~ 32,767 사이의 아무 값이나 부여됨
• 서비스 생성(.yaml)
• kubectl create -f app-service.yaml
• selector: Deployment나 ReplicaSet과 달리 matchLabels 필드가 필요하지 않고, 바로 라벨들을 나열할 수 있음(관련 글)

NameSpace

• 기본적으로 존재하는 네임 스페이스
  • kube-system
    • 쿠버네티스 주요 파드들은 kube-system 이라는 네임스페이스(like 구역)에 존재한다.
    • 이전에 만들었던 ‘nginx’ 등의 파드는 kubectl get pods를 통해 조회할 수 있었는데 이들은 네임스페이스가 ‘default’인 파드들이었기 때문.
    • kubectl get pods -n kube-system으로 조회시 apiserver, cube-proxy, kube-scheduler, controller 등이 조회된다.
  • default: default name space
  • kube-public: 모든 사용자가 사용할 수 있는 리소스가 존재하는 네임 스페이스
• 만약 개발과 생산 환경에서 같은 클러스터를 사용하고 싶은데 둘 사이의 리소스를 분리한다면 각각 다른 네임 스페이스을 만들 수 있음(개발 환경에서 작업하는 동안 프로덕션의 리소스를 실수로 수정하지 않음)
• 모든 네임스페이스에 있는 자원 조회시 --all-namespaces 옵션 사용
• kubectl get [resource type] --all-namespaces
• 네임 스페이스 각각은 고유한 정책 모음을 가질 수 있음(누가 뭘 할 수 있는지 정의)
• 각 네임 스페이스마다 리소스 할당량을 할당할 수 있음(각 네임 스페이스는 일정량을 보장받고 허용된 한도 이상을 사용하지 않음)
  • Resource Quota
    • create - f compute-quota.yaml

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

  • 네임스페이스의 리소스를 제한하기 위해 리소스 할당량(Resource Quota) 생성 가능
• 같은 네임스페이스 내에서는 각 오브젝트 간에 서로의 이름으로 호출 가능
  • 예를 들어, 같은 파드에 있다고 가정할 때 웹앱 파드는 DB파드에 접속할 때 mysql.connect("db-service"); 라고 할 수 있다.
  • 만약 다른 파드에 있는 DB파드에 접속할 때에는 mysql.connect(”db-service.dev.svc.cluster.local”); 와 같이 DNS이름을 이용해 지정할 수 있다. (이는 서비스 생성시 DNS entry가 자동으로 추가되기 때문)
    • dev: 네임스페이스
    • svc: 서비스(서비스를 위한 하위 도메인)
    • cluster.local: 도메인(쿠버네티스 클러스터의 기본 도메인)
• 파드 생성시 기본적으로 항상 default namespace에 생성되는데, 다른 네임 스페이스에 생성하고 싶다면, 1) 작성한 파일을 이용해 파드를 생성할 때 커맨드로 네임스페이스 옵션을 주거나, 2) 파드 정의 파일에서 metadata 하위에 namespace 필드를 줄 수 있다.

  apiVersion: v1
  kind: Pod
  metadata:
  	name: my-app
    namespace: [namespace-name]
  

• kubectl create -f pod-definition.yaml -n [namespace-name]
• NameSpace 생성
  • (1) YAML파일 생성(kubectl create -f namespace-definition.yml)
  • apiVersion: v1 kind: NameSpace metadata: name: [namespace-name] spec:
  • (2) create namespace
  • kubectl create namespace [namespace-name]
• 반영구적으로 다른 네임스페이스로 전환해서, 해당 네임스페이스의 파드를 조회할 때 -n 옵션을 붙이지 않아도 되는 방법(컨텍스트 전환)
• kubectl config set-context $(kubectl config current-context) --namespace=dev
• 모든 네임 스페이스의 파드 조회
• kubectl get pods --all-namespaces

Binding

apiVersion:v1
kind:Binding
metadata:
  name:[name]
target:
  apiVersion: v1
  kind: Node
  name: [node-name]

 

삭제하기(delete)

1. 파드/디플로이먼트 삭제
   • type: pod/deployment
2. kubectl delete [type] [name]
3. 파일로 삭제 가능(kubectl delete -f 파일명)

 

삭제 후 생성(delete insert)

kubectl replace --force [file-name]

 

모든 오브젝트 조회

• 보통 특정 네임스페이스 내의 오브젝트 조회 또는 특정 라벨의 오브젝트 조회로 사용된다.

kubectl get all