Kubectl
- kubectl은 kubernetes의 상태를 확인하고 원하는 상태를 요청하는 목적으로 사용된다.
- kubectl을 통해 컨테이너 로그 및 원격 접속이 가능하다.
Kubectl의 명령어
apply: 원하는 상태를 적용한다.get: 리소스 리스트를 조회한다.describe: 리소스 상태를 조회한다.delete: 리소스를 제거한다.logs: 컨테이너 로그를 조회한다.exec: 컨테이너에 명령어를 전달한다. (컨테이너 접근 시 사용 가능)config: Kubectl 설정을 관리한다.
apply
$ kubectl apply -f {파일 혹은 URL}- Desired State를 yaml로 작성하고 이를 활용하여 명령어를 적용
get
$ kubectl get {타입}
$ kubectl get {타입},{타입}
$ kubectl get all
$ kubectl get {타입} -o {원하는 포맷}
$ kubectl get {타입} -show-labelsdescribe
$ kubectl describe {타입}/{리소스 이름}
$ kubectl describe {타입} {리소스 이름}- 리소스의 상세한 상태를 확인할 수 있다.
delete
$ kubectl delete {타입}/{리소스 이름}
$ kubectl delete {타입} {리소스 이름}
$ kubectl delete -f {리소스 파일명} # 리소스 전체 제거- 특정 리소스를 제거할 수 있다.
logs
$ kubectl logs {파드 이름}
$ kubectl logs -f {파드 이름} # 실시간으로 로그를 볼 수 있다.
$ kubectl logs {파드 이름} -c {컨테이너 이름} # 여러개의 컨테이너가 있는 경우 - 로그 조회를 할 수 있다.
exec
$ kubectl exec {파드 이름} -- {커맨드}
$ kubectl exec -it {파드 이름} -- {커맨드} # 컨테이너에 접속- 컨테이너에 명령어를 전달하는 역할
- 주로 컨테이너에 접속하는 용도로 사용
- 여러 개의 컨테이너가 있을 경우 -c 옵션으로 컨테이너를 지정
config
$ kubectl config {커맨드}- 여러 개의 클러스터를 context로 설정하고 필요에 따라 선택 가능하다.
- 현재 어떤 context로 설정되어 있는지 확인 및 지정 가능
클러스터
클러스터란?
- k8s를 배포하면 클러스터를 얻는다.
- 클러스터는 컨테이너화된 애플리케이션을 실행하는 노드의 집합이다.
- 모든 클러스터는 최소 한 개 이상의 마스터 노드 및 워커 노드를 가진다.
클러스터의 2가지 영역
- 클러스터는 크게 Control Plane과 Node로 구성되어 있다.
- Control Plane : 제어 영역이며, Master Node라고 부르기도 한다.
- Node : 애플리케이션 container를 실행하는 역할이며, Worker Node라고 부르기도 한다.
Control Plane(Master Node)
- 보통 1~N개(홀수)가 존재한다.
- 클러스터의 상태를 관리하고, 명령어를 처리하는 역할을 수행한다.
- 여러 컴포넌트를 가진다. (etcd, controller-manager, scheduler, kube api server)
- 전통적인 3 tier architecture 관계와 같이 Clinet - Backend Server - Data Server의 역할을 수행하는 방식으로 진행된다.
- scheduler, controller-manager : Clinet
- kube api server : Backend Server
- etcd : Data Server
scheduler
- API 서버와 통신하는 컴포넌트이며 각각의 노드의 자원 사용 상태를 관리한다.
- 새로 생성되어 노드가 배정되지 않은 Pod에 새로운 워크로드를 띄운다.
- 이 때 자우너할당이 가능한 노드 중 적합한 노드를 선택하여 해당 노드에 워크로드를 배포하는(Pod를 띄우는) 역할을 수행한다.
controller-manager
- 여러 컨트롤러 프로세스를 관리한다.
- Kube controller-manager와 Cloud controller-manager로 나뉜다.
- Cloud controller-manager : 대표적인 클라우드 provider들과 통신한다. 각각의 클라우드 환경에 맞춘 컨트롤러가 배정되어, provider들의 종속적인 기능들을 클러스터에서 수행하는 역할을 한다.
- Kube controller-manager : API 서버에는 다양한 API resource(Pod, Deployment, Service ... )가 있으며 이를 각각 관리하는 컨트롤러가 배정된다.
- 이들은 주기적으로 현재 클러스터 상태와 etcd에 저장된 리소스의 상태를 API 서버를 통해 확인하며 etcd 리소스 변경 사항이 있다면 이를 현재 클러스터 리소스에 반영하여 동기화한다.
- 이러한 변화를 감지하고 동기화시키는 반복된 과정을 "reconcile" 이라고 칭한다.
kube api server
- k8s 리소스와 클러스터의 상태 관리 및 동기화를 위한 API를 제공한다.
- etcd를 데이터 저장소로 사용한다.
etcd
- 분산 key-value 저장소로 클러스터의 상태를 저장한다.
- 백업 및 복구에 사용할 수 있다.
Node(Worker Node)
- 클러스터 구성 목적인 애플리케이션 효율적인 관리를 위해 애플리케이션이 실질적으로 실행되는(컨테이너가 띄워지는) 공간이다.
- Node는 최소 1~n개로 구성되며, 모든 노드의 컴포넌트 구성은 동일하다.
- 기본형태는 Container Runtime 위에서 Pod가 실행되는 것이며, 그 외에 System 컴포넌트인 kubelet, kube-proxy, network-addOne과 같은 컴포넌트를 돌린다.
kubelet
- 기본적으로 설치되는 컴포넌트이다.
- API 서버와 통신하며 노드의 리소스 상태를 보고 및 관리한다.
- Container Runtime과 통신하며 해당 노드의 컨테이너 라이프사이클을 관리하기도 한다.
CRI(Container Runtime Interface)
- kubelet을 통해 다양한 컨테이너 런타임과 통신할 수 있는 인터페이스이다.
- Docker에 대한 의존성을 줄이기 위한 목적 또한 존재한다.
- docker외 containered, cri-o를 포함한 모든 CRI 구현체를 지원하며, Container Runtime은 CRI를 통해 kubelet과 통신할 수 있다.
kube-proxy
- 해당 컴포넌트는 클러스터 상에 오버레이 네트워크를 구성한다.
- 내부적으로 네트워크 프록시 및 내부 로드밸런서 역할을 수행한다.
참고: 워크로드
- 클러스터에서 실행하려는 작업 혹은 서비스, 프로세스 등 이다.
- Pod 집합을 관리하며 Pod 실행을 보장하는 API 리소스 기반의 프로세스이다.
- Deployment, ReplicaSet, StatefulSet, DaemenSet, Job, CronJob 등 다양한 API 리소스가 해당 기반이 될 수 있다.
- 쿠버네티스에서 실질적인 작업 리소스를 기반으로 구동되는 애플리케이션
manifest
API 리소스
- 쿠버네티스가 관리할 수 있는 오브젝트의 종류
- pod, service, configMap, secret 뿐만아니라, 클러스터가 사용하는 node, serviceAccount, role도 리소스로 사용 및 표현이 된다 즉 설계도이자 템플릿
- API 리소스 관련 커맨드
- kubectl api-resources : 현재 쿠버네티스가 지원하는 API 리소스 목록을 출력
- kubectl explain pod : 특정 API 리소스에 대해 간단한 설명을 확인 가능
- 스펙, 용도, 목적 등을 알 수 있다.
오브젝트
- 해당 API 리소스의 instance
API 리소스와 오브젝트의 상호작용
- 명령형이나 선언형 커맨드의 오브젝트 명세가 API 서버로 전달
- 각 API 리소스의 컨트롤러들은 API 리소스(설계도)를 참고하여 오브젝트 인스턴스를 만들어 API 서버에 업데이트를 요청
- API 서버는 위 요청에 맞게, 실제 클러스터의 오브젝트 상태를 생성 및 업데이트
- 클러스터 상태는 etcd 컴포넌트에서 관리되므로 etcd를 업데이트
- 컨트롤러는 API 서버를 통해 새로운 커맨드(오브젝트 명세)를 감시하며, 현재 클러스터의 오브젝트 상태를 감시하여 새로운 오브젝트 명세와 실제 오브젝트 상태를 비교하고 즉각 동기화 시킨다.
manifest file(Yaml)
- k8s는 오브젝트를 yaml 기반 manifest 파일로 관리한다.
- 대표적으로 apiVersion, Kind, metadata, spec가 4개의 루트키이다.
- 이 중 apiVersion, Kind, metadata는 모든 오브젝트에 반드시 존재하며 spec은 API 리소스 종류에 따라 대체되기도 한다.
루트키
- apiVersion : 오브젝트가 어떤 API 그룹에 속하며 버전을 정의
- Kind : 오브젝의 API 리소스 타입을 정의
- metadata : 오브젝트를 식별하기 위한 정보(이름, namespace, labels, annotaions 등)을 포함
- spec : 오브젝트의 desired state를 기재
Labels & Annotations
- 모든 쿠버네티스 오브젝트는 Labels와 Annotations이라는 metadata를 가진다.
- 문자열 형태의 key-value 데이터를 기록한다.
- Labels
- 오브젝트 식별 목적으로 사용한다.
- 검색, 분류, 필터링의 효율을 높이기 위한 목적으로 사용된다.
- Annotations
- 클러스터의 다양한 애드온 서비스가 존재할 때 해당 애드온이 오브젝트의 어노테이션 값에 따라 오브젝트 처리 방식을 정한다.
- 애드온 설정 용도로 사용할 수 있으며 오브젝트 처리 방식을 결정하기 위한 용도로 사용
출처 : velog
AI 새싹