Kubernetes Objects
kubectl api-resources
- Label / LabelSelector: 오브젝트와 오브젝트를 연결할 때 사용하는 개념으로 오브젝트와 오브젝트의 관계를 설명할 때 사용한다. AWS 태그같은 개념으로 생각하면 된다.
- Workload
- Pod: 제일 핵심, Pod 는 컨테이너라고 볼 수 있다.
- Controller: 파드를 제어하는 컨트롤러
- ReplicationController: ReplicaSets 가 나온 이후로 사용하지 않는다.
- ReplicaSets
- DaemonSets
- Jobs: 배치 작업
- CronJobs: 배치 작업
- Deployments: 배포, stateless 를 관리, 쿠버네티스의 핵심!
- StatefulSets: stateless 와 상반
- HorizontalPodAutoscaler(HPA): 파드의 오토 스케일링을 담당
- Network
- service: L4 LB
- Endpoints: 로드 밸런서의 백엔드
- Ingress: L7 LB, Add-on 으로 설치해야 한다.
- Storage
- PersistentVolume(PV)
- PersistentVolumeClaim(PVC): PV 를 요청
- ConfigMap: 파드에 데이터를 제공하기 위한 Key Value 스토리지
- Secret: 파드에 데이터를 제공하기 위한 Key Value 스토리지
- Authentication: ~/.kube/config 파일과 관련된 내용들이다.
- ServiceAccount(SA): 계정에 관련된 개념
- RBAC: 역할 기반의 접근 제어
- Role
- ClusterRole
- RoleBinding: (Binding)계정과 역할을 연결할 때 사용
- ClusterRoleBinding: (Binding)계정과 역할을 연결할 때 사용
- Resource Isolation
- Namespaces: 리소스를 분리하기 위해 사용한다.
- Resource Limits: 파드 리소스를 제한
- Limits
- Requests
- ResourceQuota
- LimitRange
- Schedulling
- NodeName
- NodeSelector
- Affinity(선호도)
- Node Affinity
- Pod Affinity
- Pod Anti Affinity
- Taints/Tolerations
- Drani/Cordon: Drain → 배출, Cordon → 스케줄링을 하지 않게 막아버린다. Drain 을 할 경우 자동으로 Cordon 이 작동된다.
쿠버네티스 오브젝트 이해하기
아래 명령어로 쿠버네티스 오브젝트를 확인할 수 있다.
kubectl api-resources
공식 문서: https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/kubernetes-objects/
쿠버네티스 api 공식 문서: https://kubernetes.io/ko/docs/reference/
쿠버네티스 오브젝트 는 쿠버네티스 시스템에서 영속성을 가지는 오브젝트이다. 쿠버네티스는 클러스터의 상태를 나타내기 위해 이 오브젝트를 이용한다. 구체적으로 말하자면, 다음같이 기술할 수 있다.
- 어떤 컨테이너화된 애플리케이션이 동작 중인지 (그리고 어느 노드에서 동작 중인지)
- 그 애플리케이션이 이용할 수 있는 리소스
- 그 애플리케이션이 어떻게 재구동 정책, 업그레이드, 그리고 내고장성과 같은 것에 동작해야 하는지에 대한 정책
쿠버네티스 오브젝트는 하나의 "의도를 담은 레코드"이다.
오브젝트를 생성하게 되면, 쿠버네티스 시스템은 그 오브젝트 생성을 보장하기 위해 지속적으로 작동할 것이다.
오브젝트를 생성함으로써, 여러분이 클러스터의 워크로드를 어떤 형태로 보이고자 하는지에 대해 효과적으로 쿠버네티스 시스템에 전한다. 이것이 바로 여러분의 클러스터에 대해 의도한 상태가 된다.
생성이든, 수정이든, 또는 삭제든 쿠버네티스 오브젝트를 동작시키려면, 쿠버네티스 API를 이용해야 한다.
예를 들어, kubectl 커맨드-라인 인터페이스를 이용할 때, CLI는 여러분 대신 필요한 쿠버네티스 API를 호출해 준다. 또한, 클라이언트 라이브러리 중 하나를 이용하여 내 프로그램에서 쿠버네티스 API를 직접 이용할 수도 있다.
오브젝트를 YAML 혹은 명령어로 생성할 것인지 정해야 한다.
오브젝트 명세(spec)와 상태(status)
거의 모든 쿠버네티스 오브젝트는 오브젝트의 구성을 결정해주는 두 개의 중첩된 오브젝트 필드를 포함하는데 오브젝트 spec 과 오브젝트 status 이다.
spec을 가진 오브젝트는 오브젝트를 생성할 때 리소스에 원하는 특징(의도한 상태)에 대한 설명을 제공해서 설정한다.
status 는 쿠버네티스 시스템과 컴포넌트에 의해 제공되고 업데이트된 오브젝트의 현재 상태 를 설명한다.
쿠버네티스 컨트롤 플레인은 모든 오브젝트의 실제 상태를 사용자가 의도한 상태와 일치시키기 위해 끊임없이 그리고 능동적으로 관리한다.
사용자는 보통 spec 을 작성한다. 오브젝트의 종류에 따라 spec 이 없는 경우도 있지만 극히 드물다.
아래 예제를 확인해보자.
apiVersion, kind, metadata, spec 은 모든 리소스에 항상 적용된다.
오브젝트에 따라서 지원하는 apiVersion 이 모두 다르다. 즉, apiVersion 은 오브젝트의 종류에 따라 달라진다.
kind 는 오브젝트의 종류를 나타낸다.
kubectl api-resources 명령어를 입력했을 때 맨 오른쪽에 있는 KIND 란에 있는 녀석과 똑같다.
metadata 는 오브젝트를 설명하기 위한 데이터이다.
리소스의 이름(name), 리소스의 라벨(label), 주석(annotation) 키워드 등을 사용한다.
spec 은 kind 에 따라서 달라지게 된다. 즉, 어떤 종류의 오브젝트를 정의하냐에 따라 달라진다는 것이다.
- apiVersion - 이 오브젝트를 생성하기 위해 사용하고 있는 쿠버네티스 API 버전이 어떤 것인지
- kind - 어떤 종류의 오브젝트를 생성하고자 하는지
- metadata - 이름 문자열, UID, 그리고 선택적인 네임스페이스를 포함하여 오브젝트를 유일하게 구분지어 줄 데이터
- spec - 오브젝트에 대해 어떤 상태를 의도하는지, 선언형
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
selector:
matchLabels:
app: nginx
replicas: 2 # tells deployment to run 2 pods matching the template
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
kubectl explain <오브젝트_이름>
# 해당 필드에서 사용할 수 있는 모든 필드들을 확인할 수 있다.
kubectl explain <오브젝트_이름>.<필드명> --recursive
kubectl explain <오브젝트_이름>.<필드명>.<필드명>.....
kubectl explain pods
kubectl explain pods.spec
kubectl explain pods.spec.containers
kubectl explain pods.spec.containers.ports
오브젝트의 버전
공식 문서: https://kubernetes.io/ko/docs/reference/using-api/#api-그룹
현재 쿠버네티스 버전에서 지원되는 api 버전들을 아래 명령어로 확인할 수 있다.
kubectl api-versions
- Stable
- vX
- v1, v2
- 안정화 된 버전
- Beta
- v1betaX, v2betaX
- 충분히 검증, 오류가 거의 없다.
- 버전이 올라가면 기능 변경이 있을 수 있다.
- downtime 발생할 수도 있다. 즉, 특정 기능을 사용하기 위해 재시작
- Mission Critical
- Alpha
- v1alphaX, v2alphaX
- 기본적으로 비활성화
- 개발 중인 API
Dev → Alpha → Beta → Stable
오브젝트 관리 방법
공식 문서: https://kubernetes.io/ko/docs/concepts/overview/working-with-objects/object-management/
- 명령형 커맨드: kubectl 명령어로만 구성
- kubectl create
- kubctl run
- kubctl expose
- 명령형 오브젝트 구성: YAML 파일 작성, 명령형==절차형. 오브젝트를 구성해 놓은 YAML 파일 여러개가 있을 때 이 파일을 순서대로 하나씩 실행한다.
- kubectl create -f a.yml
- kubectl apply -f a.yml
- kubectl replace -f a.yml
- 선언형 오브젝트 구성: YAML 파일 작성, YAML 파일이 있는 디렉토리를 한 번에 실행한다.
- kubectl create -f resources
- kubectl apply -f resoureces
일반적으로 명령형, 선언형 오브젝트 구성을 사용한다.