흑… 노션에서 그대로 옮기는 건, 너무 무리한 작업인 거 같다… 좀 더 효율적인 방법이 없을까
쿠버네티스
쿠버네티스 전체 개요
컨트롤 Plane(마스터 노드) -> 워커노드로 명령이 전달된다.
오브젝트
오브젝트 목록 확인
kubectl api-resources
특정 오브젝트 설명
kubectl explain pod
포드 생성
kubectl apply -f nginx-pod.yaml
포드 확인
kubectl get pdos
포드 정보 확인
kubectl describe pods {PODS_NAME}
포드 컨테이너 내부 확인
kubectl exec -it my-nginx-pod bash
포드 로그 확인
kubectl logs my-nginx-pod
포드 삭제
kubectl delete pod {POD_NAME}
🐋 YAML 파일에서 - 를 쓰는 건 여러 개의 하위항목이 있음을 의미
컨테이너 접속
kubectl exec -it my-ngnix-pod -c ubuntu-sidecar-container bash
여러 개 리소스 정의
한 번에 여러 개 포드를 생성하는 것은 비효율적인 작업이다.
포드가 생성된 노드에 장애가 생겨도 포드는 다른 노드에서 생성되지 않는다.
Replicaset
- 정해진 수의 동일한 포드가 항상 동일하게 관리합니다.
##### YAML 작성법 #####
spec.replicas = 동일한 포드를 몇 개 유지할 건지 설정
spec.templates = 포드를 사용할 때 생성할 templates를 정의
설정된 label의 리소스 필터링
kubectl get pods --show-labels
kubectl get pods -l app
kubectl edit
kubectl edit pods {PODNAME} YAML에서 지정하지 않은 옵션까지 확인할 수 있다.
K8S 좀비 클러스터 지우는 법
잘못해서 한 번 만든 k8s 클러스터가 지워지지 않는다… !
그럴 때는,
IAM에서 액세스 관리 → 역할에서 k8s master node / k8s worker node를 지우고 ec2에서 인스턴스를 종료하면 다시 살아나지 않는다 !!
Deployment
🐋 레플리카셋으로 마이크로서비스 구조의 컨테이너를 구성할 수 있을 것 같지만, ”레플리카셋과 포드의 정보를
디플로이먼트(DEPLOYMENT)라는 오브젝트에 정의한다.”
Deployment의 yaml 예시
apiVersion: apps/v1
kind: Deployment
metadata:
name: my-nginx-deployment
spec:
replicas: 3
selector:
matchLabels:
app: my-nginx
template:
metadata:
name: my-nginx-pod
labels:
app: my-nginx
spec:
containers:
- name: nginx
image: nginx:1.10
ports:
- containerPort: 80
디플로이먼트 삭제
배포하는 레플리카셋과 파드가 삭제된다.
kubectl delete deploy my-nginx-deployment
디플로이먼트 업데이트
디플로이먼트를 사용하는 이유
🐋 “애플리케이션 업데이트와 배포를 편하게 하기 위해서이다.”
업데이트 시, 레플리카셋의 변경 사항을 저장하는 리비전(revision)을 남겨 롤백 가능하게 해주고, 무중단 서비스시 포드의 롤링 업데이트의 전략을 지정할 수 있다.
어플리케이션 버전 업데이트
kubectl apply -f deployment-nginx.yaml --record
이미지 변경 업데이트 시
kubectl set image deployment my-nginx-deployment nginx=nginx:1.11 --record
리비전 정보
🐋 “디플로이먼트는 포드의 정보가 변경되어 업데이트 발생 시 → 이전의 정보를 저장한다.”
리비전 정보를 열람
kubectl rollout history deployment my-nginx-deployment
record true 옵션으로 디플로이먼트를 변경하면 변경 사항을 저장, 해당 버전의 레플리카셋을 보존
리비전 롤백 시
이전 버전의 리비전으로 롤백 시 --to-revision에는 되돌리려는 리비전의 번호를 입력
kubectl rollout undo deployment my-nginx-deployment --to-revision=1
디플로이먼트 정보 출력
kubectl describe deploy my-nginx-deployment
서비스(Service)
포드의 IP를 확인하는 방법
kubectl get pods -o wide
서비스의 종류
- Cluster IP 타입 : 쿠버네티스 내부에서만 포드들에 접근할 때 사용, 외부로 포드를 노출하지 않기 때문에 쿠버네티스 클러스터 내부에서만 사용하는 포드에 적합.
- NodePort 타입 : 포드에 접근할 수 있는 포트를 클러스터의 모든 노드에 적용, 외부에서 포드를 접근할 수 있는 서비스 타입.
- LoadBalancer 타입 : 클라우드 플랫폼에 제공하는 로드 밸런스를 동적으로 프로비저닝하여 포드에 연결. NodePort 타입과 마찬가지로 외부에서 접근 가능한 서비스. 일반적으로 AWS, GCP 등과 같은 클라우드 플랫폼 환경에서만 사용 가능.
🐋 포드를 내부에서만 접속하고 싶다. → Cluster IP 외부에서도 포드를 접근하고 싶으면 → NodePort 실제 운영 환경
→ LoadBalancer
ClusterIP 타입의 서비스
YAML 파일 형식
apiVersion: v1
kind: Service
metadata:
name: hostname-svc-clusterip
spec:
ports:
- name: web-port
port: 8080
targetPort: 80 //포드 템플릿과 같은 포트 아이피 필요
//Ip:8080-> Container port 80
selector:
app: webserver
type: ClusterIP //서비스가 어떤 타입인지 ClusterIP/ NodePort /LoadBalancer
Cluster IP 개요
NodePort 타입의 서비스
YAML 파일 형식
apiVersion: v1
kind: Service
metadata:
name: hostname-svc-nodeport
spec:
ports:
- name: web-port
port: 8080
targetPort: 80 // PublicIP:~~ -> ServicePort 8080 -> Container port 80
nodePort: ~~ // nodePort의 포트번호를 지정할 수도 있다. 보통은30000 ~ 32768 사이
selector:
app: webserver
type: NodePort
NodePort 개요
🐋 NodePort는 자동으로 ClusterIP 또한 생성하여, 내/외부 네트워크를 통해 접근 가능하다 !
LoadBalancer 타입의 서비스
YAML 파일 형식
apiVersion: v1
kind: Service
metadata:
name: hostname-svc-lb
spec:
ports:
- name: web-port
port: 80
targetPort: 80
selector:
app: webserver
type: LoadBalancer
서비스 생성 시 → External-IP 항목이 추가 , port 번호와 같이 사용하여 서비스에 접근
LoadBalancer 개요
서비스 삭제
이전 버전의 리비전으로 롤백 시 --to-revision에는 되돌리려는 리비전의 번호를 입력
kubectl rollout undo deployment my-nginx-deployment --to-revision=1
디플로이먼트 정보 출력
kubectl describe deploy my-nginx-deployment
서비스(Service)
포드의 IP를 확인하는 방법
kubectl get pods -o wide
서비스의 종류
- Cluster IP 타입 : 쿠버네티스 내부에서만 포드들에 접근할 때 사용, 외부로 포드를 노출하지 않기 때문에 쿠버네티스 클러스터 내부에서만 사용하는 포드에 적합.
- NodePort 타입 : 포드에 접근할 수 있는 포트를 클러스터의 모든 노드에 적용, 외부에서 포드를 접근할 수 있는 서비스 타입.
- LoadBalancer 타입 : 클라우드 플랫폼에 제공하는 로드 밸런스를 동적으로 프로비저닝하여 포드에 연결. NodePort 타입과 마찬가지로 외부에서 접근 가능한 서비스. 일반적으로 AWS, GCP 등과 같은 클라우드 플랫폼 환경에서만 사용 가능.
ClusterIP 타입의 서비스
YAML 파일 형식
apiVersion: v1
kind: Service
metadata:
name: hostname-svc-clusterip
spec:
ports:
- name: web-port
port: 8080
targetPort: 80 //포드 템플릿과 같은 포트 아이피 필요
//Ip:8080-> Container port 80
selector:
app: webserver
type: ClusterIP //서비스가 어떤 타입인지 ClusterIP/ NodePort /LoadBalancer
Cluster IP 개요
NodePort 타입의 서비스
YAML 파일 형식
apiVersion: v1
kind: Service
metadata:
name: hostname-svc-nodeport
spec:
ports:
- name: web-port
port: 8080
targetPort: 80 // PublicIP:~~ -> ServicePort 8080 -> Container port 80
nodePort: ~~ // nodePort의 포트번호를 지정할 수도 있다. 보통은30000 ~ 32768 사이
selector:
app: webserver
type: NodePort
NodePort 개요
🐋 NodePort는 자동으로 ClusterIP 또한 생성하여, 내/외부 네트워크를 통해 접근 가능하다 !
LoadBalancer 타입의 서비스
YAML 파일 형식
apiVersion: v1
kind: Service
metadata:
name: hostname-svc-lb
spec:
ports:
- name: web-port
port: 80
targetPort: 80
selector:
app: webserver
type: LoadBalancer
서비스 생성 시 → External-IP 항목이 추가 , port 번호와 같이 사용하여 서비스에 접근
LoadBalancer 개요
서비스 삭제
kubectl delete -f hostname-svc-lb.yaml