[CKA] 01. kubectl autocomplete | context와 manifest의 정의 | CKA 공부를 본격적으로 시작하기 전에

시작하기 전 kubectl 의 오토컴플릿을 설정한다. 

쿠버네티스 docs에서 'kubectl autocomplete'으로 검색

 

 

- Quick Reference 링크로 이동 

 

 

 

: BASH에 해당하는 autocomplete 적용 

 

source <(kubectl completion bash) # set up autocomplete in bash into the current shell, bash-completion package should be installed first.
echo "source <(kubectl completion bash)" >> ~/.bashrc # add autocomplete permanently to your bash shell.

 

 

 

 

 

- kubectl Quick Reference 의 한글 링크 활용 

 

'cheatsheet'로 검색 > 

 

 

 

- Quick Reference를 한글로 제공하니 이 페이지도 유용하게 사용하자

---

 

Manifest 

 

쿠버네티스에서 "Manifest"는 클러스터 리소스를 정의하는 데 사용되는 YAML 또는 JSON 형식의 파일이다.

이 파일은 쿠버네티스 리소스(예: Pod, Deployment, Service 등)의 구성을 선언적으로 정의하며, kubectl apply나 kubectl create 명령어를 사용해 클러스터에 적용된다.

 

1. Manifest의 주요 목적

1) 리소스 선언:
 - 쿠버네티스 리소스를 생성, 관리, 업데이트하기 위해 사용된다.
 - YAML 파일에 리소스의 상태를 정의하여 쿠버네티스 API 서버에 전달한다.

2) 구성 관리:
 - 애플리케이션과 관련된 모든 설정을 파일로 관리해 버전 관리와 재현 가능성을 보장.

3) 자동화 및 복구:
- 선언적 방식으로 리소스의 원하는 상태를 정의하면, 쿠버네티스 컨트롤러가 이를 유지.

 

 

2. Manifest의 구성 요소
Manifest 파일은 쿠버네티스 리소스를 정의하며, 일반적으로 다음과 같은 주요 필드가 포함된다.

(1) apiVersion
- 리소스를 생성하기 위해 사용하는 API의 버전을 정의.
  예:
  v1: 기본 API 버전.
  apps/v1: Deployment, ReplicaSet 등.

(2) kind
- 리소스의 유형(Pod, Deployment, Service 등)을 정의.
  예:
  Pod: 개별 컨테이너 실행.
  Deployment: ReplicaSet을 관리하여 다수의 Pod를 관리.

(3) metadata
- 리소스에 대한 메타데이터(이름, 네임스페이스, 라벨 등)를 정의.
  예:

metadata:
  name: my-app
  labels:
    app: demo

(4) spec
- 리소스의 구체적인 스펙(구성)을 정의하는 섹션.
  예: Pod의 컨테이너 정보, Deployment의 레플리카 수 등.

 

 

3. Manifest 예제
(1) Pod Manifest
- 이름이 my-pod인 Pod를 생성.
- Pod 내부에서 nginx 컨테이너 실행.

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
  labels:
    app: demo
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80

 

(2) Deployment Manifest
- 이름이 my-deployment인 Deployment를 생성.
- 3개의 Pod를 생성하고 관리.
- 각 Pod는 nginx 컨테이너를 실행.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: demo
  template:
    metadata:
      labels:
        app: demo
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

 

 

(3) Service Manifest
- my-service라는 이름의 ClusterIP 타입 Service를 생성.
- app=demo 레이블을 가진 Pod와 연결.
- 외부에서 요청이 들어오면 80번 포트를 Pod의 80번 포트로 전달.

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  selector:
    app: demo
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  type: ClusterIP

 

 

4. Manifest 파일 적용 방법
(1) 리소스 생성
작성한 Manifest 파일을 클러스터에 적용:

kubectl apply -f <manifest-file.yaml>

(2) 리소스 확인
생성된 리소스를 확인:

kubectl get <resource-type>
kubectl get pods

(3) 리소스 삭제

kubectl delete -f <manifest-file.yaml>

 

---

 

Context  

 

쿠버네티스(Kubernetes)에서 Context는 사용자가 클러스터와 상호 작용할 때 사용할 설정 세트를 지정하는 기능이다.
쿠버네티스 클라이언트인 kubectl은 다양한 클러스터, 사용자, 네임스페이스를 조합하여 작업할 수 있도록 설계되어 있다. 
Context는 이들 설정의 조합을 저장하고 빠르게 전환할 수 있도록 돕는 개념이다.

1. Context 구성 요소
- Context는 보통 ~/.kube/config 파일에 저장되며, 다음과 같은 세 가지 주요 구성 요소를 포함한다.

(1) 클러스터: 사용자가 연결할 쿠버네티스 클러스터의 정보 (API 서버 주소 포함).
(2) 사용자: 클러스터와 상호 작용할 때 사용할 인증 정보 (예: 인증 토큰, 클라이언트 인증서).
(3) 네임스페이스: 기본적으로 사용할 네임스페이스. 네임스페이스를 지정하지 않으면 default 네임스페이스가 사용된다.

2. Context를 사용하는 이유
(1) 다양한 클러스터와 환경(예: 개발, 테스트, 프로덕션)을 관리하기 쉽게 하기 위해.
(2) 매번 클러스터, 사용자, 네임스페이스 정보를 명시적으로 제공하지 않아도 되게 하기 위해.
(3) 작업 중 Context를 전환하며 빠르게 다른 클러스터 또는 네임스페이스로 작업을 변경하기 위해.

3.Context 확인 및 전환
(1) 현재 Context 확인

kubectl config current-context

(2) 사용 가능한 Context 목록 보기

kubectl config get-contexts

(3) Context 전환

kubectl config use-context <context-name>