흑… 노션에서 그대로 옮기는 건, 너무 무리한 작업인 거 같다… 좀 더 효율적인 방법이 없을까

쿠버네티스

쿠버네티스 전체 개요

image 컨트롤 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

여러 개 리소스 정의

image

한 번에 여러 개 포드를 생성하는 것은 비효율적인 작업이다.

포드가 생성된 노드에 장애가 생겨도 포드는 다른 노드에서 생성되지 않는다.

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에서 인스턴스를 종료하면 다시 살아나지 않는다 !!

image

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 개요

image

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 개요

image

🐋 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 개요

image

서비스 삭제

kubectl delete -f hostname-svc-lb.yaml