1. Kubernetes Overview
Docker
- Docker가 등장하기 전
- node.js와 같은 웹서버, mongoDB와 같은 데이터베이스, Redis와 같은 Messaging, Ansible과 같은 Orchestration 서비스들을 사용하려면 OS 버전과 호환되는지 확인이 필요함
- 신규 개발자가 들어오는 경우 환경 셋팅에 어려움이 있음 (운영체제, 버전 등)
- 개발, 테스트, 프로덕션 환경이 서로 달랐음
- Docker의 등장
- 각 구성 요소를 별도의 컨테이너에서 자체 종속성과 자체 라이브러리를 사용하여 모두 동일한 VM, OS에서 실행할 수 있게 되었음
- 컨테이너는 동일한 OS 커널을 공유하는 것 외에 자체 프로세스나 서비스, 자체 네트워크 인터페이스, 자체 마운트를 가질 수 있음
- 즉 컨테이너화 한 이미지, 라이브러리 등을 포함하여 패키징한 이미지를 통해 다른 것 신경쓰지 않고 배포만 하면되고, 이는 동일한 환경에서 동작하는 것을 보장함
- 이러한 규칙들을 적어놓은 것이 dockerfile
Container Orchestration
- Container Orchestration의 등장 배경
- 한 어플리케이션이 다른 Redis나 mongoDB 이미지를 참조하는 경우
- 어플리케이션에 부하가 많거나 줄어들어 실행시키는 어플리케이션을 확장하거나 축소해야하는 경우
- 위와 같은 경우들처럼 컨테이너를 자동으로 배포하고 관리하는 프로세스를 Orchestration이라고 하며, Kubernetes는 이러한 기술 중 하나
- Container Orchestration의 특징
- 어플리케이션의 여러 인스턴스가 서로 다른 노드에서 실행 중이므로 장애로 인해 어플리케이션이 다운되지 않음
- 트래픽이 많아지면 여러 인스턴스로 로드밸런싱될 수 있고, 필요 시 인스턴스를 쉽게 추가 배포할 수 있음
- 클러스터 환경에서 여러 인스턴스를 관리하는 것이 Container Orchestration 기술
Kubernetes Architecture
- Cluster
- Node
- Master Node : kube-API server, etcd, controller, scheduler
- Worker Node : kubelet, container runtime
- Components
- API Server : 쿠버네티스의 프론트 역할로 사용자의 명령은 모두 API Server를 통해 Kubernetes 클러스터와 통신함
- etcd : 클러스터 관리에 사용되는 모든 데이터를 저장하는 key-value 저장소
- kubelet : 클러스터의 각 노드에서 실행되는 에이전트로, 컨테이너가 정상 동작하는지 감시함
- Container Runtime : 컨테이너를 실행하는데 사용되는 기본 소프트웨어 (docker)
- Controller : 노드나 컨테이너가 다운될 때 이를 감지하고 대응하며 새로운 컨테이너를 불러오기위한 결정을 내림
- Scheduler : 여러 노드에 컨테이너를 배포하는 역할
- kubectl 명령어
- kubectl run hello-minikube
- kubectl cluster-info
- kubectl get nodes
ContainerD
- Container Runtime Interface(CRI) : rocket과 같은 docker 외의 컨테이너 런타임도 OCI 표준만 충족시킨다면 Orchestration이 가능하게 하기위해 사용되는 API 명세, kubelet은 이 CRI를 통해 컨테이너 생성, 시작, 중지 등의 요청을 보냄
- Open Container Initiative(OCI) : 이미지 사양과 런타임 사양으로 구성, 이미지 사양은 이미지를 빌드하는 방법에 대한 사양을 정의, 런타임 사양은 컨테이너 런타임을 개발하기 위한 방법을 정의
- containerd
- docker와 별도의 컨테이너 런타임으로 OCI 표준을 지원 (k8s에서 docker는 deprecated)
- 명령어 ctr : containerd를 위한 네이티브 CLI 도구
- 이미지를 가져오거나 실행할 때 사용하나, 저수준 기능으로 유저 친화적이지는 못함 → 사용하지 않는 것을 권장
- 명령어 nerdctl : containerd를 위한 Docker 호환 CLI 도구로, ctr 보다 고수준이며 Docker와 거의 유사한 사용이 가능함
- nerdctl run —name redis redis:alpine
- nerdctl run —name webserver -p 80:80 -d nginx
- 명령어 crictl : kubelet의 관점에서 디버깅하기 위한 목적
- crictl pull busybox
- crictl images
- crictl ps -a
- crictl exec -i -t ~
- crictl logs ~
- crictl pods
- 명령어 정리
- Kubernetes Pod가 왜 안 뜨는지 노드에서 확인하고 싶다면? → crictl
- Docker 없이 containerd 환경의 서버에서 컨테이너를 빌드하고 실행하고 싶다면? → nerdctl
2. Kubernetes Concepts
Setting up k8s
- local
- docker desktop
- minikube
- 마스터 노드, 워커 노드 각각 나눠져 있던 역할들이 단 하나의 노드에 존재, 이미지 패키징화
- kubeadm
- cloud
- Google Cloud Platform (GKE)
- Amazon Web Services (EKS)
- Azure (AKS)
- play ground
- KodeKloud
Pods
- pod는 어플리케이션의 단일 인스턴스로, k8s에서 가장 작은 오브젝트
- k8s는 유저 트래픽에 따라 pod를 추가 배포할 수 있으며, 한 노드에 충분한 용량이 없다면, 다른 노드에 pod를 추가 배포 할 수 있음
- 한 pod 안에는 하나의 어플리케이션 컨테이너와 함께 헬퍼 컨테이너가 함께 동작할 수 있으며, k8s는 이 두 컨테이너를 연결시켜주어 생성 시에는 함께 생성되고, 삭제 시에는 함께 삭제될 수 있도록 함
- kubectl run {podName} —image={imageName}
- ex) kubectl run nginx —image=nginx
- pod를 생성하여 docker 컨테이너를 배포하는 명령어
- 이미지는 docker hub나 private repository에서 다운로드
- kubectl get pods
- 배포된 pod들의 상태 확인
- kubectl get pods - wide
- 배포된 pod들의 상태와 함께 실행중인 노드와 pod의 ip 주소와 같은 추가 정보들을 알 수 있음
- kubectl describe pod nginx
- 특정 pod의 상세 정보 확인
- 상세 정보의 Events에서 해당 pod의 event history를 확인할 수 있음
3. YAML Introduction
YAML
- YAML은 key: value의 dictionary/map으로, array/list와 달리 순서가 중요하지 않음
- 주석은 # 를 사용
- k8s는 pod, replica, deployments, services와 같은 오브젝트를 생성하기 위해 YAML을 사용함
쿠버네티스 정의 YAML 구조
- apiVersion
- 오브젝트를 생성하는데 사용하는 k8s API의 버전
- ex) v1, apps/v1
- kind
- Pod, Service, ReplicaSet, Deployment
- metadata
- name
- labels
- app, type
- spec
- 오브젝트에 관련된 추가 정보 작성
- containers
- name, image
4. Kubernetes Concepts - Pods
Pods with YAML
- pod-definition.yml
apiVersion: v1 kind: Pod metadata: name: myapp-pod labels: app: myapp type: front-end spec: containers: - name: nginx-container image: nginx - pod 생성
- kubectl create -f pod-definition.yml
- kubectl apply -f pod-definition.yml
- YAML 파일 없이 pod 생성 : kubectl run nginx —image=nginx
- pod 상태 확인
- kubectl get pods
- kubectl get pods -o wide
- kubectl describe pod myapp-pod
Tips
- vim이나 메모장은 실수할 가능성이 많기 때문에 YAML 작성은 IDE에서 하자
- kubectl get pod 명령어 결과로 나오는 READY는 pod 안 running 상태의 컨테이너의 갯수 / pod 안 컨테이너의 총 갯수
- kubectl run redis —image=redis —dry-run -o yaml > redis.yaml
- redis pod를 생성하는데 사용할 YAML 파일 생성 (리소스 생성 X)
- —dry-run=client : API 서버에 요청을 보내지 않고 클라이언트에서만 YAML 파일 생성
- —dry-run=server : API 서버에 요청을 보내어 생성한 YAML에 대한 설정이나 유효 값 검증을 진행하고 YAML 파일 생성
- pod의 YAML 파일을 직접 수정하고 설정을 강제로 적용하는 것보단 Deployment를 통해 pod 관리하는 것이 더 좋은 방법
5. Kubernetes Concepts - ReplicaSets
ReplicaSets의 역할
- k8s에서 단일 pod의 여러 인스턴스를 실행하게 해주는 역할 → 고가용성 제공
- 기존에 있던 pod가 실패하면 자동으로 새 pod를 불러옴
- ReplicaSets을 통해 여러 개의 pod를 유지하여 부하를 분산시킬 수 있음
- 예전에는 이러한 역할을 Replication Controller가 수행했지만(deprecated), 현재는 ReplicaSets에서 수행
ReplicaSets with YAML
- rc-definition.yml
apiVersion: apps/v1 # 주의! kind: ReplicaSet metadata: name: myapp-rc labels: app: myapp type: front-end spec: template: metadata: name: myapp-pod labels: app: myapp type: front-end spec: containers: - name: nginx-container image: nginx replicas: 3 selecotor: matchLabels: type: front-end # type이 front-end인 label을 가진 pod를 선택- spec.selector는 설정된 label을 가진 pod(label이 AND 조건으로 일치해야 함)가 replicas에 설정된 갯수만큼 유지되도록 관리 (즉, label을 기준으로 관리 대상을 지정)
- pod를 수동으로 생성, 삭제하여도 설정된 pod 갯수를 유지
- spec.selector는 설정된 label을 가진 pod(label이 AND 조건으로 일치해야 함)가 replicas에 설정된 갯수만큼 유지되도록 관리 (즉, label을 기준으로 관리 대상을 지정)
- kubectl create -f rc-definition.yml
- kubectl get replicaset
- replicas 갯수를 변경하는 방법
- YAML의 replicas의 숫자를 변경하고, kubectl apply -f rc-definition.yml 명령어 실행
- kubectl scale 명령어 실행
- kubectl scale —replicas=6 -f rc-definition.yml
- kubectl scale —replicas=6 replicaset myapp-rc (TYPE NAME)
- 주의할 점은, kubectl scale 명령어로 replicas의 숫자를 변경해도, YAML 파일이 수정되는 것이 아님
- kubectl describe replicaset myapp-rc → replicaSet의 상세 정보 및 history 확인
6. Kubernetes Concepts - Deployments
Deployments의 역할
- 어플리케이션을 배포할 때, 어떠한 전략(롤링 업데이트 등)으로 갱신/배포하는지, 문제 시 어떻게 롤백할 것인지 대해 관리
- Deployments는 ReplicaSets의 상위 개념으로, Deployments를 생성하면, ReplicaSets이 생성되고, Pod가 생성됨
Deployments with YAML
- deploy-definition.yml
apiVersion: apps/v1 kind: Deployment metadata: name: myapp-deploy labels: app: myapp type: front-end spec: template: metadata: name: myapp-pod labels: app: myapp type: front-end spec: containers: - name: nginx-container image: nginx replicas: 3 selecotor: matchLabels: type: front-end - kubectl create -f deploy-definition.yml
- kubectl get all
- kubectl get deployments
- kubectl get replicaset
- kubectl get pods
Update and Rollback
- Deployment는 Revision 관리를 통해 이전 버전을 배포하거나 기존 버전을 롤백할 수 있음 (Rollout)
- Rollout 상태 확인 : kubectl rollout status deployment/myapp-deploy
- Rollout Revision과 이력 확인 : kubectl rollout history deployment/myapp-deploy
- Update 전략
- RollingUpdate : 다운타임 없이 점진적으로 Pod를 새 버전으로 교체 (default)
- Recreate : 모든 구버전 Pod를 한 번에 종료한 후, 모든 신규 버전 Pod를 한 번에 생성
- Update 방법
- Deployment YAML 파일에서 image 변경, kubectl apply -f deploy-definition.yml (권장 방법)
- kubectl set image deployment/myapp-deploy nginx=nginx:1.9.1
- Update가 진행되면, 신규 ReplicaSet을 생성하고 기존 ReplicaSet의 Pod를 하나씩 kill 하며 신규 ReplicaSet의 Pod를 하나씩 실행하게 됨
- Rollback 방법
- kubectl rollout undo deployment/myapp-deploy
- Rollback은 신규 ReplicaSet의 Pod를 하나씩 kill하며, 이전 ReplicaSet의 Pod를 하나씩 실행하게 됨
- 존재하는 ReplicaSet의 버전은 revisionHistoryLimit에 의해 조절됨
7. Networking Kubernetes
- 컨테이너마다 IP가 할당되는 Docker와 달리 k8s는 Pod마다 IP가 할당됨
- 내부 IP로 pod 간 통신은 가능하지만, IP가 고정되어 있지 않기 때문에 IP 주소를 사용하여 다른 pod를 접근하는 것은 지양해야함
- k8s 네트워크 솔루션(CNI, Container Network Interface) - CISCO ACI Network, Cilium, Flannel 등..
- 해당 솔루션은 유동적인 pod IP 대신, 가상 IP를 통해 pod를 접근할 수 있도록 함
- k8s 클러스터 내 모든 pod나 컨테이너가 NAT를 구성하지 않고도 통신이 되어야 함
- 모든 노드는 컨테이너와 통신할 수 있어야하며, 모든 컨테이너는 클러스터 내 노드와 통신할 수 있어야 함
k8s 기본 네트워킹 원칙
- 컨테이너 간 통신 : 하나의 파드(Pod) 안에 있는 여러 컨테이너들은 localhost를 통해 서로 통신할 수 있어야 함 (하나의 네트워크 네임스페이스 공유)
- 파드 간 통신 (Pod-to-Pod) : 클러스터 내의 모든 파드는 다른 모든 파드와 NAT 없이 직접 통신할 수 있어야 하며, 모든 파드는 클러스터 내에서 유일한 IP 주소를 가짐
- 파드 간 통신을 CNI(Container Network Interface)에서 담당
- 파드-서비스 통신 (Pod-to-Service) : 파드의 IP는 언제든 바뀔 수 있으므로, 안정적인 가상 IP(Virtual IP)를 제공하는 서비스(Service)를 통해 파드 그룹에 접근할 수 있어야 하며, 이 기능은 보통 각 노드에 있는 kube-proxy가 담당
- 외부-서비스 통신 (External-to-Service) : 클러스터 외부의 트래픽이 서비스를 통해 내부 파드에
도달할 수 있어야 함 (NodePort, LoadBalancer, Ingress 등을 통해 구현)
8. Services
Service의 종류
- 각 Service의 역할은 엔드포인트에서 Pod로 안정적인 접근을 할 수 있도록 하는 것
- ClusterIP (Default)
- 클러스터 내부에서만 사용하는 가상 IP로, 클러스터 내부 통신에 사용
- kube-proxy가 각 노드에서 ClusterIP로 오는 트래픽을 실제 pod로 전달함
- 주로 프론트엔드와 백엔드 간 통신에 쓰임
- NodePort
- 모든 워커 노드의 특정 포트를 통해 서비스를 외부로 노출하여, 외부에서 내부 pod에 접근할 수 있도록 하는 역할 (기본 포트 값은 30000~32767)
- NodePort 서비스를 생성하면, ClusterIP가 먼저 자동으로 생성됨
- 주로 개발이나 테스트 등 외부 접근이 필요하지만 정식 로드 밸런서를 사용하기 어려울 때 사용
- LoadBalancer
- 프로덕션 환경에서 서비스를 안정적으로 외부에 공개할 때 사용하며, 가장 안정적인 방법
- LoadBalancer는 고유한 외부 IP를 가지며, 들어온 트래픽을 모든 노드의 NordPort로 분산시켜줌
- LoadBalancer 서비스를 생성하면, NodePort와 ClusterIP가 먼저 자동으로 생성됨
각 Service 종류 별 동작
- ClusterIP
- my-service 라는 ClusterIP 서비스(10.10.1.1)를 1개 생성
- 모든 노드의 kube-proxy가 "10.10.1.1로 오는 트래픽은 파드 A, B, C 중 하나로 보내라"는 규칙을 자신의 노드에 설정
- 따라서 클러스터 내 어느 노드에서든 10.10.1.1로 접근하면 서비스 이용이 가능함
- NodePort
- my-service 라는 NodePort 서비스를 1개 생성 (ClusterIP도 자동으로 생성)
- 모든 노드의 kube-proxy가 ClusterIP 규칙을 설정함과 동시에, 자신의 노드 IP에 특정 포트(예: 30001)를 열고, "이 포트로 들어오는 트래픽은 my-service의 ClusterIP(10.10.1.1)로 보내라"는 규칙을 추가
- 따라서 어떤 노드의 IP에 30001 포트로 접근하든, 결국 동일한 서비스로 연결
- LoadBalancer:
- my-service 라는 LoadBalancer 서비스를 1개 생성
- 위의 NodePort 규칙이 모든 노드에 동일하게 적용
- 추가로 클라우드 컨트롤러가 외부 로드밸런서를 1개 생성하고, 그 로드밸런서가 모든 노드의 NodePort로 트래픽을 분산하도록 설정
ClusterIP
- 다중으로 구성되어있는 front-end, back-end 혹은 redis 간 통신을 위해, 유동적인 IP가 아닌 단일 인터페이스인 ClusterIP의 IP를 통해 통신하며, 여러 pod로 랜덤하게 요청이 들어가게 됨
- service-definition.yml
apiVersion: v1 kind: Service metadata: name: back-end spec: type: ClusterIP ports: - targetPort: 80 port: 80 selector: app: myapp type: front-end
NodePort
- service-definition.yml
apiVersion: v1 kind: Service metadata: name: myapp-service spec: type: NodePort ports: - targetPort: 80 # target pod의 port port: 80 # pod와 연결될 service의 port 값 (필수 값) nodePort: 30008 # 외부와 연결될 nodeport의 port 값 selector: # 연결될 pod의 label 값 app: myapp type: front-end - Service 생성 : kubectl create -f service-definition.yml
- Service 확인 : kubectl get services
LoadBalancer
- service-definition.yml
apiVersion: v1 kind: Service metadata: name: myapp-service spec: type: LoadBalancer ports: - targetPort: 80 port: 80 nodePort: 30008 - 외부와의 통신을 위해 사용되며, Azure나 AWS와 같은 클라우드 플랫폼에서 제공하는 기능으로 사용
- 해당 LoadBalancer는 L4 수준에서 동작하며, Nginx 인그레스 컨트롤러가 L7 수준에서 동작
L4 로드밸런서 vs L7 로드밸런서
- LoadBalancer 서비스 타입 (L4 로드밸런서)
- 동작 계층: L4 (Transport Layer - TCP/UDP)
- 네트워크 트래픽을 받아서 특정 IP 주소와 포트로 단순히 전달(pass-through)만 해주는 역할
- IP 주소와 포트 번호만 인지, HTTP 요청의 내용(예: a.com으로 가는지, b.com/path로 가는지)은 전혀 알지 못함
- K8s에서의 구현: 클라우드 플랫폼(AWS, GCP 등)의 네트워크 로드밸런서(NLB, ELB 등)를 생성, 이 로드밸런서는 외부의 공인 IP를 가지고, 들어온 요청을 등록된 노드들의
NodePort로 분산시켜주는 역할만 함 - 비유 : 도시로 들어오는 모든 우편물을 받는 중앙 우편물류센터. 이 센터는 우편물의 내용(편지 수신인)은 보지 않고, 단지 우편번호(Node IP + Port)만 보고 해당 지역의 우체국(노드)으로 우편물 자루를 통째로 보냄
- Nginx (인그레스 컨트롤러) (L7 로드밸런서)
- 동작 계층: L7 (Application Layer - HTTP/HTTPS)
- HTTP 요청의 내용을 상세히 들여다보고, 그 내용에 따라 어디로 보낼지 지능적으로
결정(라우팅)하는 역할 - 호스트 이름(a.com, b.com), 경로(/api, /images), 헤더, 쿠키 등 HTTP의 모든 정보를
인지하고 이를 바탕으로 결정을 내림 - K8s에서의 구현: Nginx 인그레스 컨트롤러 파드가 바로 이 역할을 함. L4 로드밸런서로부터 전달받은 트래픽의 내용을 보고, Ingress 규칙에 따라 적절한 내부 서비스(ClusterIP)로 요청을 다시 로드 밸런싱(프록시)
- 비유: 중앙 물류센터에서 우편물 자루를 받은 지역 우체국. 이 우체국은 이제 자루를 열어 개별 편지들의 상세 주소와 수신인 이름(호스트, 경로)을 하나하나 확인하고, 올바른 아파트/집(파드)으로 배달
- L4 로드밸런서와 L7 로드밸런서가 함께 동작하는 방식
- [외부 요청] → [L4 로드밸런서 (
LoadBalancer서비스)]- 사용자의 요청이 먼저 클라우드의 L4 로드밸런서(공인 IP)에 도달
- [L4 로드밸런서] → [Nginx 인그레스 컨트롤러 파드]
- L4 로드밸런서는 요청 내용을 보지 않고, 단순히 Nginx 인그레스 컨트롤러가 실행 중인 노드의
NodePort로 트래픽을 전달
- L4 로드밸런서는 요청 내용을 보지 않고, 단순히 Nginx 인그레스 컨트롤러가 실행 중인 노드의
- [Nginx 인그레스 컨트롤러 (L7 로드밸런서)] → [내부 서비스(ClusterIP)]
- Nginx는 이제 HTTP 요청 내용을 보고, Host 헤더가 a.com인 것을 확인
- Ingress 규칙에 따라 이 요청을 service-A의 ClusterIP로 보냄
- [내부 서비스] → [최종 파드]
- service-A는 이 요청을 최종 목적지인 파드로 전달
- [외부 요청] → [L4 로드밸런서 (
9. Microservices Architecture
Microservices Application
- docker run -d —name=redis redis
- 여기서 -d 옵션은 백그라운드에서 실행
- Link : 두 개의 컨테이너를 서로 연결하는데 사용하는 옵션
- docker run -d —name=vote -p 5000:80 —link redis:redis voting-app
- 위의 두 방법은 일시적인 방법이라 권장되지 않음
Deploying MSA on K8S - Pod
- STEP 1) Deploy Pod
- STEP 2) Enable Connectivity (via ClusterIP)
- ex) redis, db
- STEP 3) External Access (via NodePort)
- ex) app
- 디렉토리 내 모든 YAML apply : kubectl apply -f .
Deploying MSA on K&S - Deployment
- db-deployment.yaml
apiVersion: apps/v1 kind: Deployment metadata: labels: app: db name: db spec: replicas: 1 selector: matchLabels: app: db template: metadata: labels: app: db spec: containers: - image: postgres:15-alpine name: postgres env: - name: POSTGRES_USER value: postgres - name: POSTGRES_PASSWORD value: postgres ports: - containerPort: 5432 name: postgres volumeMounts: - mountPath: /var/lib/postgresql/data name: db-data volumes: - name: db-data emptyDir: {} - db-service.yaml
apiVersion: v1 kind: Service metadata: labels: app: db name: db spec: type: ClusterIP ports: - name: "db-service" port: 5432 targetPort: 5432 selector: app: db - redis-deployment.yaml
apiVersion: apps/v1 kind: Deployment metadata: labels: app: redis name: redis spec: replicas: 1 selector: matchLabels: app: redis template: metadata: labels: app: redis spec: containers: - image: redis:alpine name: redis ports: - containerPort: 6379 name: redis volumeMounts: - mountPath: /data name: redis-data volumes: - name: redis-data emptyDir: {} - redis-service.yaml
apiVersion: v1 kind: Service metadata: labels: app: redis name: redis spec: type: ClusterIP ports: - name: "redis-service" port: 6379 targetPort: 6379 selector: app: redis - result-deployment.yaml
apiVersion: apps/v1 kind: Deployment metadata: labels: app: result name: result spec: replicas: 1 selector: matchLabels: app: result template: metadata: labels: app: result spec: containers: - image: dockersamples/examplevotingapp_result name: result ports: - containerPort: 80 name: result - result-service.yaml
apiVersion: v1 kind: Service metadata: labels: app: result name: result spec: type: NodePort ports: - name: "result-service" port: 8081 targetPort: 80 nodePort: 31001 selector: app: result - vote-deployment.yaml
apiVersion: apps/v1 kind: Deployment metadata: labels: app: vote name: vote spec: replicas: 1 selector: matchLabels: app: vote template: metadata: labels: app: vote spec: containers: - image: dockersamples/examplevotingapp_vote name: vote ports: - containerPort: 80 name: vote - vote-service.yaml
apiVersion: v1 kind: Service metadata: labels: app: vote name: vote spec: type: NodePort ports: - name: "vote-service" port: 8080 targetPort: 80 nodePort: 31000 selector: app: vote - worker-deployment.yaml
apiVersion: apps/v1 kind: Deployment metadata: labels: app: worker name: worker spec: replicas: 1 selector: matchLabels: app: worker template: metadata: labels: app: worker spec: containers: - image: dockersamples/examplevotingapp_worker name: worker
10. Kubernetes on Cloud
k8s on the cloud - 종류
- Self-Hosted / Turnkey
- Hosted / Managed
- Master 노드나 VM 접근이 불가능한 경우가 많음
- GKE(Google), AKS(Azure), EKS(AWS)
공부겅부