Cloud Architect/Kubernetes

Kubernetes Object [Part 01]

"Everything about infra" 2025. 7. 18. 11:04

01. Kubernetes 오브젝트

  • kubernetes 시스템 내에서 영속성을 가지는 오브젝트
  • 클러스터의 의도한 상태를 나타내기 위해 오브젝트를 이용
  • status 필드는 kubernetes 시스템과 컴포넌트에 의해 오브젝트의 현재 상태를 나타내며, kubernetes control plane은 이 status를 사용자가 의도한 상태와 일치시키기 위해 끊임없이 능동적으로 관리한다.

💁‍♂️ 의도한 상태란?

  • 오브젝트에 대한 기본적인 정보와 의도한 상태를 기술한 오브젝트 spec을 제시
  • 오브젝트 생성을 위한 kubernetes API 요청은 JSON 형식을 포함한다.
  • 대부분의 경우 정보를 .yaml 파일로 kubectl에 제공
  • kubectl은 API 요청이 이루어질 때 JSON 형식으로 정보를 변환

deployment 라는 yaml파일 예시

 

💁‍♂️ yaml 파일 기본 구조

manifest file의 루트 레벨 구성요소 4가지는 아래와 같다.

  • apiVersion (String) : deployment 같은 경우는 apps/v1 등..
  • kind (String) : service, pod 등 ..
  • metadata (Dictionary) : 오브젝트에 부여할 이름
  • spec (Dictionary) : 만들고자 하는 오브젝트에 대해 의도한 상태를 기술하는 부분

 

사람이 작성한 yaml을 apply를 하고 나면 쿠버네티스가 이 yaml파일을 가지고 라이브 매니페스트를 만들게 됩니다.

Live형태인 pod 또는 service를 yaml 파일 형태로 변환

  • status (Dictionary) : 오브젝트의 실제 상태를 기술.

쿠버네티스 컨트롤 플레인은 오브젝트의 실제 상태를 의도한 상태에 일치시키는 방향으로 동작.

 

★ Kubernetes Object를 이해하기 위해선 선행되어야 하는 준비 조건은?

yaml 구조를 이해하고, Object를 직접 다뤄보고, Service와 Object의 관계를 이해하는 것이 중요하다고 생각한다!

 

02. Cluster Object

💁‍♂️ Worker node (data plane)란?

  • 워크로드가 돌아가는 컨테이너를 배치하는 물리(가상)머신
  • Master node (control plane)에 의해 관리된다.
  • 일반적인 운영환경 에서는 multi node로 운영된다.
  • 각 노드는 kubelet / container-runtime / kube-proxy 가 포함됨.

1. node 상태 확인

kubectl get nodes
kubectl get nodes -o wide
kubectl describe nodes [노드 이름] -- 자세하게 확인

 

2. node 상태를 yaml 파일(manifest)로 확인

node에 대한 metadata를 알아볼 수 있다.

kubectl get nodes [노드 이름] -o yaml

 

 

■ cordon & drain

  • cordon : cordon을 설정한 node에 pods들이 스케줄링 되지 않음

왜 설정할까? node에 알수없는 이슈 발생 시 문제 해결을 위해 사용합니다!!

  • drain : 지정된 node에 있는 pod들을 다른 node로 이동시키고, 클러스터에서 해당 node를 제외시킨다.

문제가 있는 node들에서 pod가 동작하면 안되기 때문에 장상적인 다른 node로 이동시킬 때 사용!!

 

kubectl cordon [노드 이름]
kubectl uncordon [노드 이름]

설정 시, node의 STATUS를 확인해보자.

 

kubectl drain [노드 이름] [플래그]
  • drain을 하기 위해선 기본적으로 cordon 설정이 선행되어야 한다

또한 Pod의 형태가 DaemonSet 형태이면 다른 Node로 옮기기 어려우며 진행 시 " —ignore-daemonsets" 라는

플래그를 필수적으로 적어주고 drain을 시키면 된다.

 

03. Namespace

  • 동일 물리 클러스터를 기반으로 하는 복수의 가상 클러스터를 지원하는 개념.
  • 클러스터를 논리적으로 나누고 액세스를 제한하여 리소스를 생성, 관리

논리적으로 구분은 되지만 격리되는 것은 아니다. 격리를 위해서는 "network policy"와 같은 다른 오브젝트를 추가적으로

사용해야 된다.

 

■ 네임스페이스 종류

  • default : pod, deployment가 생성될 때 기본적으로 생성되는 네임스페이스
  • kube-system : DNS, kube-proxy 나 kubernetes dashboard 처럼 시스템 제어 리소스가 사용
  • kube-public : 전체 클러스터 리소스에 대한 가시성을 제공 하는 경우 사용 (일반적X)

이렇게 기본적으로 제공하는 네임스페이스 말고, 커스터마이징 해서 사용할 수도 있다.

  • prometheus, ArgoCD, istio 등등의 시스템 관련 솔루션들은 독자 네임스페이스를 할당
  • microservice 별로 네임스페이스를 할당하여 논리적으로 분리

 

■ 네임스페이스 생성 확인 삭제

관리 방법은 여러가지지만, 직접 생성하고 수정할 수 있고 yaml 파일로도 생성 및 수정이 가능하다.

kubectl create namespace [이름]
kubectl get namespace
kubectl delete namespace [이름]

kubectl create namespace [이름] --dry-run=client -o yaml > namespace.yaml
kubectl apply -f namespace.yaml
kubectl delete -f namespace.yaml

 

■ 네임스페이스 조회

라벨조회, 해당 네임스페이스 파드 목록 조회, 모든 네임스페이스에 대한 내용 조회

kubectl get namespace --show-labels
kubectl get pod -n [네임스페이스 이름]
kubectl get all -n [네임스페이스 이름]
kubectl get all -A

 

💁‍♂️ Resource quota란?

네임스페이스에서 할당할 수 있는 Resource 제한을 두는 역할을 합니다.

아래 yaml 파일을 배포할 시 "dev"라는 네임스페이스에 기재되어 있는 스펙 한해서 Pods 10개를 생성할 수 있다.

apiVersion: v1
kind: Namespace
metadata:
	name: dev

---

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"

 

 

■ 네임스페이스에 종속되어 있는 하위 Resource 확인

kubectl api-resources --namespaced=true

 

위 명령을 통해 api resource들을 확인할 수 있다.

  • api resource가 namespace 기반인지 (true, false로 확인)
  • api resource의 약어 (ex: namespace는 ns로 불린다)
  • kind가 무엇인지
  • 사용할 수 있는 권한(verb)가 무엇인지.