Skip to content

Kubernetes:Basic

Kubernetes 기초.

시작해 보기

Kubectl 기본 명령

API 서버는 json 또는 protobuf 형식을 이용한 http 통신을 지원합니다. 이 방식을 그대로 쓰면 불편하므로 보통 kubectl이라는 명령행 도구를 사용합니다. 앞으로 엄청나게 많이 지겹게 사용할 예정입니다. 어떻게 읽어야 할지 난감한데 공식적으로 큐브컨트롤(cube control)이라고 읽지만 큐브씨티엘, 쿱컨트롤, 쿱씨티엘등도 많이 쓰입니다.

  • apply - 원하는 상태를 적용합니다. 보통 -f 옵션으로 파일과 함께 사용합니다.
  • get - 리소스 목록을 보여줍니다.
  • describe - 리소스의 상태를 자세하게 보여줍니다.
  • delete - 리소스를 제거합니다.
  • logs - 컨테이너의 로그를 봅니다.
    • kubectl logs -f xxxx --since=5m - 5분전 로그 확인
    • kubectl logs -f deployment/mobile-php --all-containers=true --since=5m - 전체 pod 의 로그 확인 (replica 세팅시 동일한 컨테이너가 올라가면 어떤 pod 을 확인해야 모를 때 사용)
  • exec - 컨테이너에 명령어를 전달합니다. 컨테이너에 접근할 때 주로 사용합니다.
  • config - kubectl 설정을 관리합니다.

쿠버네티스 아키텍처

컨테이너는 아주 심플하고 우아하게 동작합니다. run을 하면 실행되고 stop을 하면 멈춥니다.

서버-클라이언트 구조를 안다면 컨테이너를 관리하는 에이전트를 만들고 중앙에서 API를 이용하여 원격으로 관리하는 모습을 쉽게 그려볼 수 있습니다.

Kubernetes-server-agent.png

쿠버네티스 또한 중앙(Master)에 API 서버와 상태 저장소를 두고 각 서버(Node)의 에이전트(kubelet)와 통신하는 단순한 구조입니다.

하지만, 앞에서 얘기한 개념을 여러 모듈로 쪼개어 구현하고 다양한 오픈소스를 사용하기 때문에 설치가 까다롭고 언뜻 구성이 복잡해 보입니다.

마스터 - 노드 구조

Kubernetes-master-node.png

쿠버네티스는 전체 클러스터를 관리하는 마스터와 컨테이너가 배포되는 노드로 구성되어 있습니다.

모든 명령은 마스터의 API 서버를 호출하고 노드는 마스터와 통신하면서 필요한 작업을 수행합니다.

특정 노드의 컨테이너에 명령하거나 로그를 조회할 때도 노드에 직접 명령하는 게 아니라 마스터에 명령을 내리고 마스터가 노드에 접속하여 대신 결과를 응답합니다.

Desired State

현재 상태(Current State) 에서 원하는 상태(Desired State) 로 이전시킨다.

Kubernetes-desired-state.jpg

쿠버네티스에서 가장 중요한 것은 desired state (원하는 상태) 라는 개념입니다.

원하는 상태라 함은
관리자가 바라는 환경을 의미하고
좀 더 구체적으로는 얼마나 많은 웹서버가 떠 있으면 좋은지, 몇 번 포트로 서비스하기를 원하는지 등을 말합니다.

쿠버네티스는 복잡하고 다양한 작업을 하지만 자세히 들여다보면 "현재 상태 (current state)" 를 모니터링하면서 관리자가 설정한 원하는 상태를 유지하려고 내부적으로 이런저런 작업을 하는 단순한(?) 로직을 가지고 있습니다.

이러한 개념 때문에 관리자가 서버를 배포할 때 직접적인 동작을 명령하지 않고 상태를 선언하는 방식을 사용합니다.

예를 들어 "nginx 컨테이너를 실행해줘. 그리고 80 포트로 오픈해줘."는 현재 상태를 원하는 상태로 바꾸기 위한 명령(imperative)이고 "80 포트를 오픈한 nginx 컨테이너를 1개 유지해줘"는 원하는 상태를 선언 (declarative)한 것입니다. 더 이해가 안 된다

언뜻 똑같은 요청을 단어를 살짝 바꿔 말장난하는 게 아닌가 싶은데, 이런 차이는 CLI 명령어에서도 드러납니다. 

$ docker run # 명령
$ kubectl create # 상태 생성 (물론 kubectl run 명령어도 있지만 잘 사용하지 않습니다)

쿠버네티스의 핵심은 상태이며 쿠버네티스를 사용하려면 어떤 상태가 있고 어떻게 상태를 선언하는지를 알아야 합니다.

  • Replication Controller
  • Endpoint Controller
  • Namespace Controller
  • Custom Controller
    • ML Controller
    • CI/CI Controller

Master

마스터 서버는 다양한 모듈이 확장성을 고려하여 기능별로 쪼개져 있는 것이 특징 고통 입니다.

관리자만 접속할 수 있도록 보안 설정을 해야 하고 마스터 서버가 죽으면 클러스터를 관리할 수 없기 때문에 보통 3대를 구성하여 안정성을 높입니다.

AWS EKS 같은 경우 마스터를 AWS에서 자체 관리하여 안정성을 높였고(마스터에 접속 불가) 개발 환경이나 소규모 환경에선 마스터와 노드를 분리하지 않고 같은 서버에 구성하기도 합니다.

Kubernetes-master-component.png

Kubernetes-architecture-master.png\

API Server ((kube-apiserver)

REST API, etcd와 유일하게 통신하는 모듈, 권한 체크, 등 ...

API 서버는 모오오든 요청을 처리하는 마스터의 핵심 모듈입니다. kubectl의 요청뿐 아니라 내부 모듈의 요청도 처리하며 권한을 체크하여 요청을 거부할 수 있습니다. 실제로 하는 일은 원하는 상태를 key-value 저장소에 저장하고 저장된 상태를 조회하는 매우 단순한 작업입니다. Pod을 노드에 할당하고 상태를 체크하는 일은 다른 모듈로 분리되어 있습니다. 노드에서 실행 중인 컨테이너의 로그를 보여주고 명령을 보내는 등 디버거 역할도 수행합니다.

API 서버는 요청을 받으면 etcd 저장소와 통신할 뿐 실제로 상태를 바꾸는 건 스케줄러와 컨트롤러 입니다.

현재 상태를 모니터링하다가 원하는 상태와 다르면 각자 맡은 작업을 수행하고 상태를 갱신합니다.

분산 데이터 저장소 etcd

RAFT 알고리즘을 이용한 key-value 저장소입니다. 여러 개로 분산하여 복제할 수 있기 때문에 안정성이 높고 속도도 빠른 편입니다. 단순히 값을 저장하고 읽는 기능뿐 아니라 watch 기능이 있어 어떤 상태가 변경되면 바로 체크하여 로직을 실행할 수 있습니다.

클러스터의 모든 설정, 상태 데이터는 여기 저장되고 나머지 모듈은 stateless하게 동작하기 때문에 etcd만 잘 백업해두면 언제든지 클러스터를 복구할 수 있습니다. etcd는 오직 API 서버와 통신하고 다른 모듈은 API 서버를 거쳐 etcd 데이터에 접근합니다.

k3s 같은 초경량 쿠버네티스 배포판에서는 etcd대신 sqlite를 사용하기도 합니다.

스케줄러 (kube-scheduler)

새로 생성된 pod 를 감시, 노드의 현재 상태와 pod의 요구사항 체크 (ex. 노드에 라벨 부여, 특정 라벨의 노드에 배포 - gpu-zone -)

스케줄러는 할당되지 않은 Pod을 여러 가지 조건(필요한 자원, 라벨)에 따라 적절한 노드 서버에 할당해주는 모듈입니다.

큐브 컨트롤러 (kube-controller-manager)

다양항 컨트롤러 존재, 복잡도 낮추기 위해 단일 프로세스로 실행.

큐브 컨트롤러는 다양한 역할을 하는 아주 바쁜 모듈입니다. 쿠버네티스에 있는 거의 모든 오브젝트의 상태를 관리합니다.

오브젝트별로 철저하게 분업화되어 Deployment는 ReplicaSet을 생성하고 ReplicaSet은 Pod을 생성하고 Pod은 스케줄러가 관리하는 식입니다.

  • 복제 컨트롤러
  • 노드 컨트롤러
  • 엔드포인트 컨트롤러

클라우드 컨트롤러 (cloud-controller-manager)

클라우드 컨트롤러는 AWS, GCE, Azure 등 클라우드에 특화된 모듈입니다.

노드를 추가/삭제하고 로드 밸런서를 연결하거나 볼륨을 붙일 수 있습니다.

각 클라우드 업체에서 인터페이스에 맞춰 구현하면 되기 때문에 확장성이 좋고 많은 곳에서 자체 모듈을 만들어 제공하고 있습니다.

Node

노드 서버는 마스터 서버와 통신하면서 필요한 Pod을 생성하고 네트워크와 볼륨을 설정합니다. 실제 컨테이너들이 생성되는 곳으로 수백, 수천대로 확장할 수 있습니다. 각각의 서버에 라벨을 붙여 사용목적(GPU 특화, SSD 서버 등)을 정의할 수 있습니다.

Module_03_nodes.svg.png

파드는 언제나 노드 상에서 동작한다. 노드는 쿠버네티스에서 워커 머신을 말하며 클러스터에 따라 가상 또는 물리 머신일 수 있다. 각 노드는 컨트롤 플레인에 의해 관리된다. 하나의 노드는 여러 개의 파드를 가질 수 있고, 쿠버네티스 컨트롤 플레인은 클러스터 내 노드를 통해서 파드에 대한 스케쥴링을 자동으로 처리한다. 컨트롤 플레인의 자동 스케줄링은 각 노드의 사용 가능한 리소스를 모두 고려한다.

모든 쿠버네티스 노드는 최소한 다음과 같이 동작한다.

  • Kubelet은, 쿠버네티스 컨트롤 플레인과 노드 간 통신을 책임지는 프로세스이며, 하나의 머신 상에서 동작하는 파드와 컨테이너를 관리한다.
  • 컨테이너 런타임(도커와 같은)은 레지스트리에서 컨테이너 이미지를 가져와 묶여 있는 것을 풀고 애플리케이션을 동작시키는 책임을 맡는다.

가장 보편적인 운용업무는 다음 kubectl 명령어를 이용하여 처리할 수 있다:

언제 애플리케이션이 배포되었으며, 현재 상태가 어떠한지, 그것의 구성은 어떠한지 등을 보기 위해 이러한 명령을 이용할 수 있다.

Node 구성 요소

Kubernetes-node-component.png

큐블릿 (kubelet)

노드에 할당된 Pod의 생명주기를 관리합니다. Pod을 생성하고 Pod 안의 컨테이너에 이상이 없는지 확인하면서 주기적으로 마스터에 상태를 전달합니다. API 서버의 요청을 받아 컨테이너의 로그를 전달하거나 특정 명령을 대신 수행하기도 합니다.

프록시 (kube-proxy)

큐블릿이 Pod을 관리한다면 프록시는 Pod으로 연결되는 네트워크를 관리합니다.

TCP, UDP, SCTP 스트림을 포워딩하고 여러 개의 Pod을 라운드로빈 형태로 묶어 서비스를 제공할 수 있습니다.

초기에는 kube-proxy 자체가 프록시 서버로 동작하면서 실제 요청을 프록시 서버가 받고 각 Pod에 전달해 주었는데 시간이 지나면서 iptables를 설정하는 방식으로 변경되었습니다.

iptables에 등록된 규칙이 많아지면 느려지는 문제 때문에 최근 IPVS를 지원하기 시작했습니다.

컨테이너 런타임 인터페이스 (Container runtime interface; CRI)

컨테이너는 도커고 도커가 컨테이너라고 생각해도 무리가 없는 상황이지만 쿠버네티스는 CRI (Container runtime interface)를 구현한 다양한 컨테이너 런타임을 지원합니다.

containerd(사실상 도커..), rkt, CRI-O 등이 있습니다.

CNI (네트워크)

CSI(스토리지)

하나의 Pod이 생성되는 과정

위에서 이야기한 조각을 하나하나 모아서 전체적인 흐름을 살펴보겠습니다. 관리자가 애플리케이션을 배포하기 위해 ReplicaSet을 생성하면 다음과 같은 과정을 거쳐 Pod을 생성합니다.

Kubernetes-create-replicaset.png

흐름을 보면 각 모듈은 서로 통신하지 않고 오직 API Server와 통신하는 것을 알 수 있습니다. API Server를 통해 etcd에 저장된 상태를 체크하고 현재 상태와 원하는 상태가 다르면 필요한 작업을 수행합니다. 각 모듈이 하는 일을 보면 다음과 같습니다.

  • kubectl
    • ReplicaSet 명세를 yml파일로 정의하고 kubectl 도구를 이용하여 API Server에 명령을 전달
    • API Server는 새로운 ReplicaSet Object를 etcd에 저장
  • Kube Controller
    • Kube Controller에 포함된 ReplicaSet Controller가 ReplicaSet을 감시하다가 ReplicaSet에 정의된 Label Selector 조건을 만족하는 Pod이 존재하는지 체크
    • 해당하는 Label의 Pod이 없으면 ReplicaSet의 Pod 템플릿을 보고 새로운 Pod(no assign)을 생성. 생성은 역시 API Server에 전달하고 API Server는 etcd에 저장
  • Scheduler
    • Scheduler는 할당되지 않은(no assign) Pod이 있는지 체크
    • 할당되지 않은 Pod이 있으면 조건에 맞는 Node를 찾아 해당 Pod을 할당
  • Kubelet
    • Kubelet은 자신의 Node에 할당되었지만 아직 생성되지 않은 Pod이 있는지 체크
    • 생성되지 않은 Pod이 있으면 명세를 보고 Pod을 생성
    • Pod의 상태를 주기적으로 API Server에 전달

이제 복잡했던 그림이 이해되시나요? 위의 예제는 ReplicaSet에 대해 다뤘지만 모든 노드에 Pod을 배포하는 DaemonSet도 동일한 방식으로 동작합니다. DaemonSet controller와 Scheduler가 전체 노드에 대해 Pod을 할당하면 kubelet이 자기 노드에 할당된 Pod을 생성하는 식입니다.

각각의 모듈이 각자 담당한 상태를 체크하고 독립적으로 동작하는 것을 보면서 참 잘 만든 마이크로서비스 구조라는 생각이 듭니다.

kubelet

kube-proxy

  • 네트워크 프록시와 부하 분산
  • 예전엔 프록시 프로그램을 사용했지만, 성능상의 이유로 시스템 레벨의 iptables 또는 ipvs를 사용. (설정만 관리)

DNS

Dashboard

RBAC (role-based access control)

접근 권한 시스템입니다. 각각의 리소스에 대해 유저별로 CRUD스런 권한을 손쉽게 지정할 수 있습니다. 클러스터 전체에 적용하거나 특정 네임스페이스에 적용할 수 있습니다. AWS의 경우 IAM을 연동해서 사용할 수도 있습니다.

CRD (Custom Resource Definitaion)

쿠버네티스가 제공하지 않는 기능을 기본 기능과 동일한 방식으로 적용하고 사용할 수 있습니다.

예를 들어, 쿠버네티스는 기본적으로 SSL 인증서 관리 기능을 제공하지 않지만, cert-manager를 설치하고 Certificate 리소스를 이용하면 익숙한 쿠버네티스 명령어로 인증서를 관리할 수 있습니다.

또 다른 도구, 방식을 익힐 필요 없이 다양한 기능을 손쉽게 확장할 수 있습니다.

Auto Scaling

CPU, memory 사용량에 따른 확장은 기본이고 현재 접속자 수와 같은 값을 사용할 수도 있습니다.

  • 컨테이너의 개수를 조정하는 Horizontal Pod Autoscaler(HPA),
  • 컨테이너의 리소스 할당량을 조정하는 Vertical Pod Autoscaler(VPA),
  • 서버 개수를 조정하는 Cluster Autosclaer(CA)

방식이 있습니다.

Federation, Multi Cluster

클라우드에 설치한 쿠버네티스 클러스터와 자체 서버에 설치한 쿠버네티스를 묶어서 하나로 사용할 수 있습니다.

구글에서 발표한 Anthos를 이용하면 한 곳에서 여러 클라우드의 여러 클러스터를 관리할 수 있습니다.

Cluster (쿠버네티스 클러스터)

쿠버네티스는 컴퓨터들을 연결하여 단일 형상으로 동작하도록 컴퓨팅 클러스터를 구성하고 높은 가용성을 제공하도록 조율한다.

사용자는 쿠버네티스의 추상화 개념을 통해 개별 머신에 얽매이지 않고 컨테이너화된 애플리케이션을 클러스터에 배포할 수 있다. 이렇게 새로운 배포 모델을 활용하려면, 애플리케이션을 개별 호스트에 독립적인 방식으로 패키징할 필요가 있다. 즉, 컨테이너화가 필요하다. 예전 배치 모델인 설치형 애플리케이션이 특정 머신의 호스트와 밀접하게 통합되는 패키지인 것에 비해, 컨테이너화된 애플리케이션은 유연성(flexible)과 가용성(available)이 훨씬 높다.

쿠버네티스는 이러한 애플리케이션 컨테이너를 클러스터에 분산시키고 스케줄링하는 일을 더욱 효율적으로 자동화한다.

쿠버네티스는 오픈소스 플랫폼이며 운영 수준의 안정성(production-ready)을 제공한다.

쿠버네티스 클러스터는 두 가지 형태의 자원으로 구성된다.

  • 컨트롤 플레인은 클러스터를 조율한다.
  • 노드는 애플리케이션을 구동하는 작업자(worker)이다.

Module_01_cluster.svg.png

Kubernetes Object

Kubernetes-deployment-replicaset-pod.png

Pod

  • 가장 작은 배포 단위.
  • 이 안에 여러 컨테이너가 존재할 수 있다.

Module_03_pods.svg.png

파드는 하나 또는 그 이상의 애플리케이션 컨테이너 (도커와 같은)들의 그룹을 나타내는 쿠버네티스의 추상적 개념으로 일부는 컨테이너에 대한 자원을 공유한다. 그 자원은 다음을 포함한다:

  • 볼륨과 같은, 공유 스토리지
  • 클러스터 IP 주소와 같은, 네트워킹
  • 컨테이너 이미지 버전 또는 사용할 특정 포트와 같이, 각 컨테이너가 동작하는 방식에 대한 정보

파드는 특유한 "로컬호스트" 애플리케이션 모형을 만들어. 상대적으로 밀접하게 결합되어진 상이한 애플리케이션 컨테이너들을 수용할 수 있다. 가령, 파드는 Node.js 앱과 더불어 Node.js 웹서버에 의해 발행되는 데이터를 공급하는 상이한 컨테이너를 함께 수용할 수 있다. 파드 내 컨테이너는 IP 주소, 그리고 포트 스페이스를 공유하고 항상 함께 위치하고 함께 스케쥴링 되고 동일 노드 상의 컨텍스트를 공유하면서 동작한다.

파드는 쿠버네티스 플랫폼 상에서 최소 단위가 된다. 우리가 쿠버네티스에서 배포를 생성할 때, 그 배포는 컨테이너 내부에서 컨테이너와 함께 파드를 생성한다. 각 파드는 스케쥴 되어진 노드에게 묶여지게 된다. 그리고 (재구동 정책에 따라) 소멸되거나 삭제되기 전까지 그 노드에 유지된다. 노드에 실패가 발생할 경우, 클러스터 내에 가용한 다른 노드들을 대상으로 스케쥴되어진다.

ReplicaSet

  • 복제본 만들 때 사용

Deployment

버전 업데이트, 그리고 롤백

Deployment는 Kubernetes 가 애플리케이션의 인스턴스를 어떻게 생성하고 업데이트해야 하는지를 지시합니다.

Deployment가 만들어지면, Kubernetes Master 가 해당 Deployment 에 포함된 애플리케이션 인스턴스가 클러스터의 개별 노드에서 실행되도록 스케줄합니다.

Service

Kubernetes-nodeport.png

ClusterIP

클러스터 내부에서 사용하는 프록시. 타입을 지정하지 않으면 기본으로 설정되며, 클러스터 내부의 파드에서 서비스의 이름으로 접근할 수 있다.

NodePort

ClusterIP 의 접근 범위뿐만 아니라 K8s 클러스터 외부에서도 노드의 IP 주소와 포트 번호로 접근할 수 있다.

모든 노드에 동일한 포트로 생성된다.

서비스 타입에 NodePort 를 지정하면, 앞서 설명한 ClusterIP 의 기능에 더해 노드의 IP 주소에 공개 포트가 열린다. 이를 통해 K8s 클러스터 외부에서 내부의 파드에 요청을 보낼 수 있게 된다.

공개 포트번호의 범위는 기본적으로 30000 - 32767 이다.

클라이언트가 노드의 IP와 포트로 전송한 요청은 최종적으로 파드에 전달된다.

LoadBalancer

NodePort 의 접근 범위뿐만 아니라 K8s 클러스터 외부에서도 대표 IP 주소로 접근할 수 있다.

로드밸런서와 연동하여 파드의 애플리케이션을 외부에 공개한다.

ExternalName

파드에서 K8s 클러스터 외부의 엔드포인트에 접속하기 위한 이름을 해결해 준다.

예를 들어, 퍼블릭 클라우드의 데이터 베이스나 인공지능 API 서비스 등을 접근할 때 사용될 수 있다.

ExternalName은 서비스의 이름과 외부 DNS 이름의 매핑을 내부 DNS에 설정한다. 이를 통해 파드는 서비스의 이름으로 외부 네트워크의 엔드포인트에 접근할 수 있다. 이때 포트 번호까지는 지정할 수 없다.

이 서비스 타입은 파드에서 외부의 엔드포인트에 접속할 때 편리하다. (DB 서버) 네임스페이스에서의 서비스 이름으로 ip 주소를 얻을 수 있기 때문이다. 또한, K8s 클러스터 내의 서비스로 교체하기도 쉽다.

Ingress

Kubernetes-ingress.jpg

Volume

  • Storage (e.g. EBS, NFS, ...)

Namespace

쿠버네티스에서, 네임스페이스 는 단일 클러스터 내에서의 리소스 그룹 격리 메커니즘을 제공한다. 리소스의 이름은 네임스페이스 내에서 유일해야 하며, 네임스페이스 간에서 유일할 필요는 없다. 네임스페이스 기반 스코핑은 네임스페이스 기반 오브젝트 (예: 디플로이먼트, 서비스 등) 에만 적용 가능하며 클러스터 범위의 오브젝트 (예: 스토리지클래스, 노드, 퍼시스턴트볼륨 등) 에는 적용 불가능하다.

Kubernetes-namespace-and-label.png

하나의 클러스터를 논리적으로 구분하여 사용할 수 있습니다. 하나의 클러스터에 다양한 프레임워크와 애플리케이션을 설치하기 때문에 기본(system, default)외에 여러 개의 네임스페이스를 사용하는 것이 일반적입니다. 더 세부적인 설정으로 라벨 기능을 적극적으로 사용하여 유연하면서 확장성 있게 리소스를 관리할 수 있습니다.

kubectl get namespaces 명령어를 사용해 클러스터의 현재 네임스페이스를 나열한다. 

NAME          STATUS    AGE
default       Active    11d
kube-system   Active    11d
kube-public   Active    11d

쿠버네티스를 시작하면 세 개의 초기 네임스페이스가 있다.

  • default - 다른 네임스페이스가 없는 오브젝트를 위한 기본 네임스페이스
  • kube-system - 쿠버네티스 시스템에서 생성된 오브젝트의 네임스페이스
  • kube-public - 이 네임스페이스는 자동으로 생성되며 모든 사용자(미인증 사용자를 포함)가 읽을 수 있다. 이 네임스페이스는 일부 리소스를 공개적으로 보고 읽을 수 있어야 하는 경우에 대비하여 대부분이 클러스터 사용을 위해 예약돼 있다. 그러나 이 네임스페이스의 공개적인 성격은 관례일 뿐 요구 사항은 아니다.

새 네임스페이스 생성하기

INFORMATION

kube- 접두사는 쿠버네티스 시스템 네임스페이스로 예약돼 있으므로 이를 사용해 네임스페이스를 생성하지 않도록 한다.

  • my-namespace.yaml이라는 YAML 파일을 생성하고 아래 내용을 작성한다. 
apiVersion: v1
kind: Namespace
metadata:
  name: <insert-namespace-name-here>

다음 명령을 실행한다. 

kubectl create -f ./my-namespace.yaml

아래 명령으로 네임스페이스를 생성할 수도 있다. 

kubectl create namespace <insert-namespace-name-here>

ConfigMap/Secret

  • 설정

ServiceAccount

  • 권한 계정

Role/ClusterRole

  • 권한 설정 (get, list, watch, create, ...)

일반적인 구성

Kubernetes-general-configuration.png

앱 외부로 노출하기

앱 스케일링하기

Module_05_scaling1.svg.png
Module_05_scaling1.svg.png

앱 업데이트하기

Module_05_scaling2.svg.png<ref>파일명 맞다

"Module_06_rollingupdates1.svg.png" 파일과 동일해서 안올렸다.

</ref>
Module_06_rollingupdates2.svg.png
Module_06_rollingupdates3.svg.png
Module_06_rollingupdates4.svg.png

k3s 설치

kubectl 사용법

Helm

k8s 이용해서 웹 서버 구축하기

Node.js 어플리케이션을 배포한 후 Kubernetes 로 실행하는 방법

Dockerfile 작성: 

FROM somansh1206/nodejs
WORKDIR /usr/src/app
COPY . .
RUN \
  npm install && \
  npm install gulp -g && \
  npm install swagger -g && \
  gulp clean && \
  gulp tsc
CMD [ "node", "app.js" ]

Kubernetes yaml 파일 작성: 

apiVersion: apps/v1
kind: Deployment
metadata:
 name: sample-nodejs
 labels:
   app: sample-nodejs
spec:
 selector:
  matchLabels:
   app: sample-nodejs
 template:
  metadata:
   labels:
    app: sample-nodejs
  spec:
   containers:
   - image: ip_address_of_the_machine:5000/nodejs-api-image:latest
     name: nodejs-api
     imagePullPolicy: Always
     ports:
       - containerPort: 3000
---
apiVersion: v1
kind: Service
metadata:
    name: sample-nodejs-svc
spec:
    ports:
    - name: “sample-nodejs”
      targetPort: 3000
      port: 3000
      nodePort: 30253
      protocol: TCP
    selector:
       app: sample-nodejs
    type: NodePort

k3s로 싱글 노드 쿠버네티스 구축하고 Traefik으로 포트 오픈 및 배포

See also

Favorite site