용어정리::kubctl
kubctl
- 얘는 쿠버네티스 클러스터를 관리하기 위한 커맨드라인 도구 이다.
- 다양한 리소스를 생성, 조회, 업데이트, 삭제 할수 있다.
- 기타 모니터링, 디버깅 할수도 있다.
기본 구성과 정보 조회
kubectl version- 클라이언트와 서버의 쿠버네티스 버전 출력
kubectl config view- kubctl의 현재 설정을 보여준다.
kubectl cluster-info- 클러스터의 마스터와 서비스의 엔드포인트 정보를 출력한다.
kubectl get node- 클러스터에 있는 모든 노드를 나열한다.
리소스 작업
kubectl create -f <file>- YAML 또는 JSON 파일을 사용하여 리소스를 생성한다.
kubectl get <resource>- 특정 타입의 모든 리소스를 나열한다.(kubectl get pods)
kubectl describe <resoucre> <name>- 클러스터 리소스의 상세정보를 출력한다.
kubectl logs <pod-name>- 특정 파드의 로그를 출력한다.
kubectl exec <pod-name> -- <command>- 파드 내에서 커맨드 실행한다.
리소스 업데이트 및 삭제
kubectl apply -f <file>- 파일을 사용해서 리소스를 생성하거나 업데이트 한다.
kubectl delete <resource> <name>- 특정 리소스를 삭제 한다.
kubectl scale --replicas=<count> <resoucre>/<name>- 리소스의 복제본 수를 조정한다..
kubectl set image <resource>/<name> <container-name>=<image>- 파드의 컨테이너 이미지를 업데이트한다 .
디버깅 및 진단
kubectl exec -it <pod-name> --/bin/bash- 파드 내부에 bash shell 시작.
kubectl port-forward <pod-name> <local-port>:<pod-port>- 로컬 컴퓨터와 파드 간에 포트 포워딩을 설정한다.
kubectl top pod- 파드의 리소스 사용량을 보여준다.
kubectl logs -f <pod-name>- 파드의 로그를 실시간으로 스트림 한다.
네임스페이스와 컨텍스트
컨텍스트 란 뭐냐?
- 쿠버네티스에서 컨텍스트는 클러스터, 사용자, 네임스페이스를 포함하는 구성 정보를 의미합니다
- kubectl 명령어를 사용할 때 컨텍스트는 어떤 클러스터에 명령을 보낼것인지
- 어떤 사용자 인증 정보를 사용할 것인지,
- 그리고 명령이 실행될 네임스페이스는 어디인지를 결정하는데 사용된다.
-> 컨텍스트 란?
- 컨텍스트 설정해 놓으면 (네임스페이스같이?) 그 안에서 yaml, yml ... 등 설정 파일을 찾는다.
- 즉 도커처럼 한곳에 도커파일 있는데 그거 실행하고 다른 도커파일 있는곳에 실행하면 컨테이너가 또 생기는데
- 쿠버네티스 클러스터는 같은 컨텍스트 범위면 위치가 달라져도 다른 클러스터가 생기지 않는다.
- 또한 그 컨텍스트 안의 모든영역에서 설정파일 yaml, yml .. 파일들을 탐색한다. ( 경로지정 안해줘도 되는것 같다 알아서)
네임스페이스란 머냐?
- 프로젝트간 클러스터 리소스를 격리하는 용도로 네임스페이스를 쓴다.
- 네임스페이스는 하나의 물리적인 클러스터를 여러 가상의 클러스터 처럼 사용할수있게 해준다.
- 즉 리소스를 그룹화 해서 관리할수있다.
- 기본 네임스페이스
default:
- 내가 할당 하지 않을경우 디폴트로 사용되는 네임스페이스
kube-system:
- Kubernetes 시스템에서 생성된 리소스가 위치하는 네임스페이스 , 시스템 컴포넌트가 정상작동하기 위해 사용됨.
kube-public:
- 클러스터 전체에서 공개적으로 접근 가능한 리소스를 위한 네임스페이스
- 예. 클러스터 정보를 포함한 ConfigMap이 이 네임스페이스에 위치할수 있다.
kube-node-lease:
- 각 노드의 lease 객체를 위한 네임스페이스,
- 노드의 가용성을 보다 효율적으로 관리하기 위함.
kubectl get namespaces- 모든 네임스페이스를 나열한다.
kubectl config current-context- 현재 컨텍스트를 출력한다.
kubectl config use-context <context-name>- 사용할 컨텍스트를 변경한다..
kubectl -n <namespace> <command>- 특정 네임스페이스에서 커맨드를 실행한다.
kubectl <command> --help
Namespce 문법 in yaml
- in kubernets
apiVersion :v1
kind: Pod
metadata:
name: my-pod
namespace: my-namespace
spec:
containers:
- name: my-container
image: nginx- in kustomize
- kustomize 사용하면
kustomization.yaml파일 내에서 전역적으로 네임스페이스를 지정할수 있다. - 이렇게 하면 해당 Kustomize 설정을 적용할때 모든리소스가 지정된 네임스페이스로 배포된다.
- kustomize 사용하면
# kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomiztion
namespace: my-namespace
resource:
- deployment.yaml
- service.yaml- 여기서
namespace: my-namespace라고 지정하면resource에 명시된 모든 리소스 들은 my-namespace에 배포된다.
여기서 apiVersion, kind 에 있는것도 법칙이 있다.
- apiVersion : Kustomize의 스키마 버전을 지정
- kustomize.config.k8s.io/v1beta1은 Kustomize의 특정 API 버전을 나타냅니다. 이 값은 Kustomize의 버전에 따라 달라질 수 있으며, 정확한 값을 사용해야 합니다
- kind: 리소스 유형
- Kustomize 설정의 경우, Kustomization이라는 값이 사용됩니다.
kustomize 에 대해서!
- 쿠버네티스 리소스의 구성을 관리하는 도구.
- kubectl과 함꼐 사용될수 있다.
- kustomize는 오버레이(overlay) 와 (baes) 구조를 사용하여
- 리소스 정의를 재사용하고
- 다양한 환경 (개발, 스테이징, 프로덕션 등) 에 맞게 쉽게 커스터마이징 가능!
빌드 하는법
kustomize build . --enable-helm kustomize build . --enable-helm | kubectl apply -f -
kustomize 기본구조
kustomization.yaml파일을 사용해서 리소스의 구성을 관리한다.- 이파일에서 리소스파일, 컨피스맵, 시크릿, 패치 등을 정의할수있다.
패치란?
- 기존 리소스의 일부를 업데이트 하는 작업을 의미.
- 리소스(예.포드,서비스,디플로이먼트 등) 는 YAML또는 JSON 형식의 매니페스트 파일을 통해 생성 및 구성 된다.
- 수정후 전체 매니페스트 파일을 다시 적용 하느 ㄴ대신
- 변경하고자 하는 부분만 선택적으로 업데이트 하는걸 패치 라 한다.
- 쿠버네티스 패치 전략
- Strategic Merge Patch
- 특정 필드를 업데이트하거나 배열 내 항목을 수정할때 사용
- 리소스의 특정 부분만을 명시적으로 변경할수 있다.
- 주로
kubectl patch과 함께 사용 된다.
- JSON Patch
- Json 형식을 사용해서 리소스의 변경 사항을 명시하는 방법이다.
- RFC 6902에서 정의된 표준으로 배열에 항목을 추가하거나
- 특정 경로의 값을 변경하는 드의 작업을 수행 할수 있다.
- Merge Patch
- 간단한 형태의 변경을 적용할때 사용된다.
- 리소스의 원하는 부분에 대해 새로운 값을 제공하면 해당 부분만 업데이트 된다.(RFC 7386)
- Strategic Merge Patch
- ex
kubectl patch deployment my-depolyment -p '{"spec":{"replicas":5}}- 이건 my-dep~ 라는 디플로이먼트의 레플리카 수를 5개로 변경한다.
-p옵션은 패치할 내용을 JSON 형식으로 제공한다.
패치 기능을 사용하면, 전체 리소스를 재배포하지 않고도 필요한 변경 사항을 빠르게 적용할 수 있어 운영 효율성을 높일 수 있습니다.
오버레이 사용
- 다양한 환경에 대해 공통된 베이스 구성을 사용하면서 각 환경의 특성에 맞게 오버레이를 통해 차이점을 적용할 수 있다.
오버레이란?
- 기본 구성에 추가적인 설정이나 변경사항을 적용하는 방법을 의미
- kustomize 도구를 사용할때 자주 등장
- 오버레이는 애플리케이션의 베이스 구성 위에 환경별(개발, 스테이징, 프로덕션)또는 요구사항별로 구성 변경사항을 적용하는데 사용된다.
- 베이스 디렉토리는 애플리케이션의 공통 구성을 담고
- 오버레이 디렉토리는 특정 환경이나 요구사항에 맞게 베이스 구성을 수정하거나 확장하는 파일 포함
- 예)
- 프로덕션 환경에는 디버깅 정보를 제거하고 리소스 할당을 늘리는 등의 변경사항을 오버레이를 통해 적용할 수 있다.
- 오버레이는 네트워크는 클러스 내의 포드간 통신을 가능하게 하는 가상 네트워크를 제공한다.
- 구성 관리의 오버레이는 애플리케이션 베이스 구성에 특정 환경이나 요구 사항에 맞는 변경사항을 쉽게 적용할 수 있게 해준다.
명령어
- 리소스 적용
kubectl apply -k ./path/to/kustomization
- 리소스 빌드 및 출력
kubectl kustomize ./path/to/kustomization
- kustomize 를 사용하면 리소스 정의의 중복을 줄이고, 관리를 간소화 할수 있다.
- 예를 들어 개발과 프로덕션 환경에서 실행할 애플리케이션의 설정이 다를경우 ,
- 베이스 구성은 동일하게 유지하고 오버레이를 통해 각 환경의 특성을 반영할수있다.
kustomize 구조
.
├── base
│ ├── deployment.yaml
│ ├── kustomization.yaml
│ └── service.yaml
└── overlays
├── development
│ ├── kustomization.yaml
│ └── replica_count.yaml
├── production
│ ├── kustomization.yaml
│ └── replica_count.yaml
└── staging
├── kustomization.yaml
└── replica_count.yaml일단 얘의 구조를 이해하고
다음 내가 사용하는 곳의 구조를 이해해 보자
base
- 애플리케이션의 기본 구성을 포함.
- 애플리케이션을 실행하는데 필요한 모든 쿠버네티스 리소스 정의(예.Deployment, Service)와 함께 기본
kustomization.yaml파일이 포함.
overlays
- 각 하위 디렉토리 (ex.development,production,staging)은 특정 환경에 대한 구성 변경 사항을 포함.
kustomization.yaml파일은 해당 환경에 대한 변경사항(예.이미지 태그, 리플리카수)를 적용하기 위해 base디렉토리를 참조한다.
코드 예시
Base 디렉토리
- base/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-app
spec:
replicas: 1
selector:
matchLabels:
app: my-app
template:
metadata:
labels:
app: my-app
sepc:
containers:
- name: my-app
image: my-app:tag
ports:
- containerPort: 80- base/service.yaml
apiVersion: v1
kind: Service
metadata:
name: my-app
spec:
ports:
- port: 80
targetPort: 80
selector:
app: my-app포드와 레플리카 레플리카셋과 디플로이먼트
정리해
be pro