CNI 란 무엇입니까?
Cloud Native Computing Foundation 프로젝트인 CNI(Container Network Interface)는 Linux 컨테이너에서 네트워크 인터페이스를 구성하기 위한 플러그인을 작성하기 위한 사양 및 라이브러리와 여러 플러그인으로 구성됩니다. CNI는 컨테이너의 네트워크 연결과 컨테이너가 삭제될 때 할당된 리소스 제거에만 관련됩니다.

Kubernetes는 네트워크 공급자와 Kubernetes Pod 네트워킹 간의 인터페이스로 CNI를 사용합니다.

CNI(Container Network Interface)는 Calico, Flannel, weave 및 Terway와 같은 많은 CNI 플러그인이 있습니다.

다양한 CNI 구현 모드를 살펴보겠습니다.

CNI 플러그인은 오버레이, 라우팅 및 언더레이의 세 가지 구현 모드가 있습니다.

• 오버레이 모드에서 컨테이너는 호스트의 IP 주소 범위와 무관합니다. 호스트 간 통신 중에 호스트 간에 터널이 설정되고 컨테이너 CIDR 블록의 모든 패킷은 기본 물리적 네트워크의 호스트 간에 교환되는 패킷으로 캡슐화됩니다. 이 모드는 기본 네트워크에 대한 종속성을 제거합니다.
• 라우팅 모드에서 호스트와 컨테이너는 서로 다른 CIDR 블록에 속합니다. 호스트 간 통신은 라우팅을 통해 구현됩니다. 패킷 캡슐화를 위해 서로 다른 호스트 간에 터널이 설정되지 않습니다. 그러나 경로 상호 연결은 기본 네트워크에 부분적으로 의존합니다. 예를 들어, 기본 네트워크에서 레이어 2로 연결 가능한 경로가 있어야 합니다.
• Underlay 모드에서 컨테이너와 호스트는 동일한 네트워크 계층에 있으며 동일한 위치를 공유합니다. 컨테이너 간의 네트워크 상호 연결은 기본 네트워크에 따라 다릅니다. 따라서 이 모드는 기본 기능에 크게 의존합니다.

CNI network providers using this network model include Flannel, Canal, and Weave.

CNI network providers using this network model include Calico and Romana.

클러스터 외부 네트워킹
이 섹션에서는 클러스터 외부의 트래픽이 Kubernetes 클러스터 내에서 실행되는 애플리케이션에 도달하는 방법을 설명합니다. 이 정보는 클러스터의 애플리케이션 및 워크로드를 설계할 때 중요합니다.
Kubernetes가 서비스를 사용하여 Pod 내에서 실행되는 애플리케이션에 안정적인 IP 주소를 제공하는 방법에 대해 이미 읽었습니다. kube-proxy가 각 노드의 모든 트래픽을 관리하기 때문에 기본적으로 Pod는 외부 IP 주소를 노출하지 않습니다. Pod와 해당 컨테이너는 자유롭게 통신할 수 있지만 클러스터 외부의 연결은 서비스에 액세스할 수 없습니다. 예를 들어, 이전 그림에서 클러스터 외부의 클라이언트는 해당 ClusterIP를 통해 프런트엔드 서비스에 액세스할 수 없습니다.
GKE는 액세스를 제어하고 클러스터 전체에 가능한 한 균등하게 들어오는 트래픽을 분산하기 위해 세 가지 유형의 부하 분산기를 제공합니다. 여러 유형의 로드 밸런서를 동시에 사용하도록 하나의 서비스를 구성할 수 있습니다.

• External Load Balancers : 외부 부하 분산기는 클러스터 외부 및 Google Cloud Virtual Private Cloud(VPC) 네트워크 외부에서 들어오는 트래픽을 관리합니다. GCP 네트워크와 연결된 전달 규칙을 사용하여 트래픽을 Kubernetes 노드로 라우팅합니다.
• Internal Load Balancers  : 내부 부하 분산기는 동일한 VPC 네트워크 내에서 들어오는 트래픽을 관리합니다. 외부 부하 분산기와 마찬가지로 GCP 네트워크와 연결된 전달 규칙을 사용하여 트래픽을 Kubernetes 노드로 라우팅합니다.
• HTTP(S) Load Balancers  : HTTP(S) 로드 밸런서는 HTTP(S) 트래픽에 사용되는 특수 외부 로드 밸런서입니다. 트래픽을 Kubernetes 노드로 라우팅하기 위해 전달 규칙 대신 Ingress 리소스를 사용합니다.

트래픽이 Kubernetes 노드에 도달하면 로드 밸런서 유형에 관계없이 동일한 방식으로 처리됩니다. 로드 밸런서는 클러스터의 어떤 노드가 해당 서비스에 대해 포드를 실행하고 있는지 인식하지 못합니다. 대신 관련 Pod를 실행하지 않는 노드를 포함하여 클러스터의 모든 노드에서 트래픽의 균형을 유지합니다. 지역 클러스터에서 로드는 클러스터 지역의 모든 영역에 있는 모든 노드에 분산됩니다. 트래픽이 노드로 라우팅되면 노드는 트래픽을 동일한 노드 또는 다른 노드에서 실행 중인 Pod로 라우팅합니다. 노드는 kube-proxy가 노드에서 관리하는 iptables 규칙을 사용하여 무작위로 선택된 파드로 트래픽을 전달합니다.

Container-native load balancing

컨테이너 네이티브 로드 밸런싱을 사용하면 여러 종류의 로드 밸런서가 Pod를 직접 대상으로 지정하고 해당 트래픽을 Pod에 고르게 분산할 수 있습니다.
컨테이너 네이티브 로드 밸런싱은 NEG(네트워크 엔드포인트 그룹)라는 데이터 모델을 활용합니다. NEG는 IP 포트 쌍으로 표시되는 네트워크 끝점의 모음입니다.
NEG를 GKE 인그레스와 함께 사용하면 인그레스 컨트롤러가 L7 부하 분산기의 모든 측면을 쉽게 생성할 수 있습니다. 여기에는 가상 IP 주소 생성, 전달 규칙, 상태 확인, 방화벽 규칙 등이 포함됩니다.
유연성을 높이기 위해 독립 실행형 NEG를 만들 수도 있습니다. 이 경우 L7 로드 밸런서의 모든 측면을 만들고 관리해야 합니다.

katacoda란

쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, 확장가능한 오픈소스 플랫폼이다. 쿠버네티스는 선언적 구성과 자동화를 모두 용이하게 해준다. 쿠버네티스는 크고, 빠르게 성장하는 생태계를 가지고 있다. 쿠버네티스 서비스, 기술 지원 및 도구는 어디서나 쉽게 이용할 수 있다.

쿠버네티스란 명칭은 키잡이(helmsman)나 파일럿을 뜻하는 그리스어에서 유래했다. K8s라는 표기는 "K"와 "s"와 그 사이에 있는 8글자를 나타내는 약식 표기이다. 구글이 2014년에 쿠버네티스 프로젝트를 오픈소스화했다. 쿠버네티스는 프로덕션 워크로드를 대규모로 운영하는 15년 이상의 구글 경험과 커뮤니티의 최고의 아이디어와 적용 사례가 결합되어 있다

minikube란

katacoda 접속 및 실습

하나의 node에 쿠버네티스 클러스터를 실행하는 실습입니다.

katacoda 접속

아래 ULR(katacoda 홈페이지)에 접속한 후  계정이 있을 경우 기존 계정을 사용하고 계정이 없을 경우 신규 계정을 생성하여 로그인합니다.

https://www.katacoda.com/ 

로그인 후 첫 페이지에서 "Kubernetes Introduction" 강의의 시작하기 위해 [Start Course]를 클릭합니다.

20여개의 시나리오들이 있습니다.

"Launch A Single Node Cluster" 시나리오부터 시작합니다. "Start Scenario"를 클릭합니다.

"Minikube는 Kubernetes를 로컬에서 쉽게 실행할 수 있는 도구입니다.

Minikube는 Kubernetes를 사용해 보거나 일상적으로 개발하려는 사용자를 위해 노트북의 VM 내에서 단일 노드 Kubernetes 클러스터를 실행합니다." 라는 설명이 나오면 "Start Scenario"를 클릭합니다.

실습

Step 1 - minikube 시작하기

좌측 화면의 설명을 읽으면서 실습을 진행합니다. Step1은 minikube로 kubernetes cluster를 구성하는 실습입니다.

실습할 때 좌측의 명령어를 클릭하면 우측 터미널창에 명령어가 자동으로 수행됩니다.

또는 우측 터미널창에 직접 타입핑하여 명령어를 입력하고 수행할 수 있습니다.

실습을 완료하였으면 [CONTINUE] 버튼을 클릭합니다.

Step 2 - Cluster Info

Kubernetes 클러스터는 kubectl 명령어를 사용하여 상호 작용할 수 있습니다.

클러스터 위에서 실행되는 Kubernetes 및 애플리케이션을 관리하는 데 사용하는 도구입니다.

step 2에서는 kubectl 명령어로 클러스터 정보와 노드 정보를 확인해 봅니다. master node 가 있는 것을 볼 수 있습니다.

Step 3 - Deploy Containers

kubectl create 명령어로 클러스터에 컨테이너가 배포될수 있도록

kubectl create 는 파일 또는 표준 입력으로부터 리소스를 생성하는 명령어입니다.

[참고]

• kubectl create : 파일 또는 표준 입력으로부터 리소스를 생성
• kubectl apply : 파일명 또는 표준 입력으로 리소스에 구성 적용
• kubectl run : 클러스터에서 특정 이미지 실행

kubectl run 과 kubectl create 차이는?

Step 4 - Dashboard

dashboard를 활성화합니다.

쿠버네티스는 컨테이너화된 워크로드와 서비스를 관리하기 위한 이식성이 있고, 확장가능한 오픈소스 플랫폼이다. 쿠버네티스는 선언적 구성과 자동화를 모두 용이하게 해준다. 쿠버네티스는 크고, 빠르게 성장하는 생태계를 가지고 있다. 쿠버네티스 서비스, 기술 지원 및 도구는 어디서나 쉽게 이용할 수 있다.

쿠버네티스란 명칭은 키잡이(helmsman)나 파일럿을 뜻하는 그리스어에서 유래했다. K8s라는 표기는 "K"와 "s"와 그 사이에 있는 8글자를 나타내는 약식 표기이다. 구글이 2014년에 쿠버네티스 프로젝트를 오픈소스화했다. 쿠버네티스는 프로덕션 워크로드를 대규모로 운영하는 15년 이상의 구글 경험과 커뮤니티의 최고의 아이디어와 적용 사례가 결합되어 있다.

여정 돌아보기

시간이 지나면서 쿠버네티스가 왜 유용하게 되었는지 살펴보자.

전통적인 배포 시대: 초기 조직은 애플리케이션을 물리 서버에서 실행했었다. 한 물리 서버에서 여러 애플리케이션의 리소스 한계를 정의할 방법이 없었기에, 리소스 할당의 문제가 발생했다. 예를 들어 물리 서버 하나에서 여러 애플리케이션을 실행하면, 리소스 전부를 차지하는 애플리케이션 인스턴스가 있을 수 있고, 결과적으로는 다른 애플리케이션의 성능이 저하될 수 있었다. 이에 대한 해결책은 서로 다른 여러 물리 서버에서 각 애플리케이션을 실행하는 것이 있다. 그러나 이는 리소스가 충분히 활용되지 않는다는 점에서 확장 가능하지 않았으므로, 물리 서버를 많이 유지하기 위해서 조직에게 많은 비용이 들었다.

가상화된 배포 시대: 그 해결책으로 가상화가 도입되었다. 이는 단일 물리 서버의 CPU에서 여러 가상 시스템 (VM)을 실행할 수 있게 한다. 가상화를 사용하면 VM간에 애플리케이션을 격리하고 애플리케이션의 정보를 다른 애플리케이션에서 자유롭게 액세스 할 수 없으므로, 일정 수준의 보안성을 제공할 수 있다.

가상화를 사용하면 물리 서버에서 리소스를 보다 효율적으로 활용할 수 있으며, 쉽게 애플리케이션을 추가하거나 업데이트할 수 있고 하드웨어 비용을 절감할 수 있어 더 나은 확장성을 제공한다. 가상화를 통해 일련의 물리 리소스를 폐기 가능한(disposable) 가상 머신으로 구성된 클러스터로 만들 수 있다.

각 VM은 가상화된 하드웨어 상에서 자체 운영체제를 포함한 모든 구성 요소를 실행하는 하나의 완전한 머신이다.

컨테이너 개발 시대: 컨테이너는 VM과 유사하지만 격리 속성을 완화하여 애플리케이션 간에 운영체제(OS)를 공유한다. 그러므로 컨테이너는 가볍다고 여겨진다. VM과 마찬가지로 컨테이너에는 자체 파일 시스템, CPU 점유율, 메모리, 프로세스 공간 등이 있다. 기본 인프라와의 종속성을 끊었기 때문에, 클라우드나 OS 배포본에 모두 이식할 수 있다.

컨테이너는 다음과 같은 추가적인 혜택을 제공하기 때문에 인기가 있다.

• 기민한 애플리케이션 생성과 배포: VM 이미지를 사용하는 것에 비해 컨테이너 이미지 생성이 보다 쉽고 효율적임.
• 지속적인 개발, 통합 및 배포: 안정적이고 주기적으로 컨테이너 이미지를 빌드해서 배포할 수 있고 (이미지의 불변성 덕에) 빠르고 효율적으로 롤백할 수 있다.
• 개발과 운영의 관심사 분리: 배포 시점이 아닌 빌드/릴리스 시점에 애플리케이션 컨테이너 이미지를 만들기 때문에, 애플리케이션이 인프라스트럭처에서 분리된다.
• 가시성(observability): OS 수준의 정보와 메트릭에 머무르지 않고, 애플리케이션의 헬스와 그 밖의 시그널을 볼 수 있다.
• 개발, 테스팅 및 운영 환경에 걸친 일관성: 랩탑에서도 클라우드에서와 동일하게 구동된다.
• 클라우드 및 OS 배포판 간 이식성: Ubuntu, RHEL, CoreOS, 온-프레미스, 주요 퍼블릭 클라우드와 어디에서든 구동된다.
• 애플리케이션 중심 관리: 가상 하드웨어 상에서 OS를 실행하는 수준에서 논리적인 리소스를 사용하는 OS 상에서 애플리케이션을 실행하는 수준으로 추상화 수준이 높아진다.
• 느슨하게 커플되고, 분산되고, 유연하며, 자유로운 마이크로서비스: 애플리케이션은 단일 목적의 머신에서 모놀리식 스택으로 구동되지 않고 보다 작고 독립적인 단위로 쪼개져서 동적으로 배포되고 관리될 수 있다.
• 리소스 격리: 애플리케이션 성능을 예측할 수 있다.
• 자원 사용량: 리소스 사용량: 고효율 고집적.

쿠버네티스가 왜 필요하고 무엇을 할 수 있나

컨테이너는 애플리케이션을 포장하고 실행하는 좋은 방법이다. 프로덕션 환경에서는 애플리케이션을 실행하는 컨테이너를 관리하고 가동 중지 시간이 없는지 확인해야 한다. 예를 들어 컨테이너가 다운되면 다른 컨테이너를 다시 시작해야 한다. 이 문제를 시스템에 의해 처리한다면 더 쉽지 않을까?

그것이 쿠버네티스가 필요한 이유이다! 쿠버네티스는 분산 시스템을 탄력적으로 실행하기 위한 프레임 워크를 제공한다. 애플리케이션의 확장과 장애 조치를 처리하고, 배포 패턴 등을 제공한다. 예를 들어, 쿠버네티스는 시스템의 카나리아 배포를 쉽게 관리 할 수 있다.

쿠버네티스는 다음을 제공한다.

• 서비스 디스커버리와 로드 밸런싱 쿠버네티스는 DNS 이름을 사용하거나 자체 IP 주소를 사용하여 컨테이너를 노출할 수 있다. 컨테이너에 대한 트래픽이 많으면, 쿠버네티스는 네트워크 트래픽을 로드밸런싱하고 배포하여 배포가 안정적으로 이루어질 수 있다.
• 스토리지 오케스트레이션 쿠버네티스를 사용하면 로컬 저장소, 공용 클라우드 공급자 등과 같이 원하는 저장소 시스템을 자동으로 탑재 할 수 있다.
• 자동화된 롤아웃과 롤백 쿠버네티스를 사용하여 배포된 컨테이너의 원하는 상태를 서술할 수 있으며 현재 상태를 원하는 상태로 설정한 속도에 따라 변경할 수 있다. 예를 들어 쿠버네티스를 자동화해서 배포용 새 컨테이너를 만들고, 기존 컨테이너를 제거하고, 모든 리소스를 새 컨테이너에 적용할 수 있다.
• 자동화된 빈 패킹(bin packing) 컨테이너화된 작업을 실행하는데 사용할 수 있는 쿠버네티스 클러스터 노드를 제공한다. 각 컨테이너가 필요로 하는 CPU와 메모리(RAM)를 쿠버네티스에게 지시한다. 쿠버네티스는 컨테이너를 노드에 맞추어서 리소스를 가장 잘 사용할 수 있도록 해준다.
• 자동화된 복구(self-healing) 쿠버네티스는 실패한 컨테이너를 다시 시작하고, 컨테이너를 교체하며, '사용자 정의 상태 검사'에 응답하지 않는 컨테이너를 죽이고, 서비스 준비가 끝날 때까지 그러한 과정을 클라이언트에 보여주지 않는다.
• 시크릿과 구성 관리 쿠버네티스를 사용하면 암호, OAuth 토큰 및 SSH 키와 같은 중요한 정보를 저장하고 관리 할 수 있다. 컨테이너 이미지를 재구성하지 않고 스택 구성에 시크릿을 노출하지 않고도 시크릿 및 애플리케이션 구성을 배포 및 업데이트 할 수 있다.

쿠버네티스가 아닌 것

쿠버네티스는 전통적인, 모든 것이 포함된 Platform as a Service(PaaS)가 아니다. 쿠버네티스는 하드웨어 수준보다는 컨테이너 수준에서 운영되기 때문에, PaaS가 일반적으로 제공하는 배포, 스케일링, 로드 밸런싱과 같은 기능을 제공하며, 사용자가 로깅, 모니터링 및 알림 솔루션을 통합할 수 있다. 하지만, 쿠버네티스는 모놀리식(monolithic)이 아니어서, 이런 기본 솔루션이 선택적이며 추가나 제거가 용이하다. 쿠버네티스는 개발자 플랫폼을 만드는 구성 요소를 제공하지만, 필요한 경우 사용자의 선택권과 유연성을 지켜준다.

쿠버네티스는:

• 지원하는 애플리케이션의 유형을 제약하지 않는다. 쿠버네티스는 상태 유지가 필요 없는(stateless) 워크로드, 상태 유지가 필요한(stateful) 워크로드, 데이터 처리를 위한 워크로드를 포함해서 극단적으로 다양한 워크로드를 지원하는 것을 목표로 한다. 애플리케이션이 컨테이너에서 구동될 수 있다면, 쿠버네티스에서도 잘 동작할 것이다.
• 소스 코드를 배포하지 않으며 애플리케이션을 빌드하지 않는다. 지속적인 통합과 전달과 배포, 곧 CI/CD 워크플로우는 조직 문화와 취향에 따를 뿐만 아니라 기술적인 요구사항으로 결정된다.
• 애플리케이션 레벨의 서비스를 제공하지 않는다. 애플리케이션 레벨의 서비스에는 미들웨어(예, 메시지 버스), 데이터 처리 프레임워크(예, Spark), 데이터베이스(예, MySQL), 캐시 또는 클러스터 스토리지 시스템(예, Ceph) 등이 있다. 이런 컴포넌트는 쿠버네티스 상에서 구동될 수 있고, 쿠버네티스 상에서 구동 중인 애플리케이션이 Open Service Broker 와 같은 이식 가능한 메커니즘을 통해 접근할 수도 있다.
• 로깅, 모니터링 또는 경보 솔루션을 포함하지 않는다. 개념 증명을 위한 일부 통합이나, 메트릭을 수집하고 노출하는 메커니즘을 제공한다.
• 기본 설정 언어/시스템(예, Jsonnet)을 제공하거나 요구하지 않는다. 선언적 명세의 임의적인 형식을 목적으로 하는 선언적 API를 제공한다.
• 포괄적인 머신 설정, 유지보수, 관리, 자동 복구 시스템을 제공하거나 채택하지 않는다.
• 추가로, 쿠버네티스는 단순한 오케스트레이션 시스템이 아니다. 사실, 쿠버네티스는 오케스트레이션의 필요성을 없애준다. 오케스트레이션의 기술적인 정의는 A를 먼저 한 다음, B를 하고, C를 하는 것과 같이 정의된 워크플로우를 수행하는 것이다. 반면에, 쿠버네티스는 독립적이고 조합 가능한 제어 프로세스들로 구성되어 있다. 이 프로세스는 지속적으로 현재 상태를 입력받은 의도한 상태로 나아가도록 한다. A에서 C로 어떻게 갔는지는 상관이 없다. 중앙화된 제어도 필요치 않다. 이로써 시스템이 보다 더 사용하기 쉬워지고, 강력해지며, 견고하고, 회복력을 갖추게 되며, 확장 가능해진다.

다음 내용 

GKE 란

GKE(Google Kubernetes Engine)는 Google 인프라를 사용하여 컨테이너 애플리케이션을 배포, 관리 및 확장할 수 있는 관리형 서비스입니다. Kubernetes Engine 환경은 컨테이너 클러스터를 구성하도록 그룹화된 여러 머신( Compute Engine 인스턴스)으로 구성되어 있습니다.

GKE(Google Kubernetes Engine) 클러스터는 Kubernetes 오픈소스 클러스터 관리 시스템을 기반으로 합니다.

GKE 클러스터 생성하기

1. Autopilot 모드의 클러스터 생성

구글 콘솔에서 "Kubernetes Engine" - "클러스터" 메뉴를 클릭한 후 [만들기] 버튼을 클릭합니다.

아래와 같이 GKE Standard와 GKE Autopilot 모드가 나타나는데 원하는 클러스터 모드를 선택합니다.

본 문서에서는 Autopilot 모드와 Standard 모드를 설명합니다.

먼저 Autopilot 모드의 클러스터 생성하기 입니다.

Standard 모드 VS Autopilot 모드 비교

클러스터 만들기 화면의 우측 상단에 "비교"를 클릭하면 두 모드를 비교한 화면이 아래와 같이 나타납니다.

Standard 모드는 클러스터를 사용자가 직접 관리해야 합니다.

Autopilot 모드는 클러스터 관리 부담이 상대적으로 적습니다. 비용 이점도 큽니다. 

Autopilot 클러스터 만들기

클러스터 이름과 리전을 지정하고 [만들기] 버튼을 클릭하여 Autopilot 클러스터를 생성합니다.

아래는 autopilot 클러스터가 생성된 화면입니다. 노드수와 총vCPU, 총메모리를 보면 값이 없거나 0인데 이는 아직 실행되는 pod가 없기 때문입니다. 반면 standard 모드의 클러스터는 실행하는 pod가 없어도 노드가 생성됩니다.

(참고) standard mode 클러스터 : 노드수와 총vCPU, 총메모리를 보면 값이 설정되어 있습니다.

어플리케이션 배포

nginx 배포 테스트를 하기 위해 아래 내용들을 수행합니다.

작업부하

Kubernetes Engine 하위의 "작업 부하" 메뉴를 클릭한 후 [배포]를 클릭합니다.

아래 화면이 나오면 [계속] 버튼을 클릭합니다.

아래 화면에서 [배포] 버튼을 클릭합니다. 이전에 생성한 클러스터에 배포를 진행합니다. 클러스터 항목에 이전에 생성한 클러스터가 선택되어 있는지 확인합니다.

아래와 같이 3개의 pod가 생성된 것을 볼 수 있습니다.

외부와 통신하기 위해 [노출] 버튼을 클릭합니다. 아래 화면이 나타나면 "포트1"에 서비스 포트 입력, "대상포트1"에는 컨테이너의 포트입니다. 쉽게 말해 "포트1"은 node의 포트이고 "대상포트1"은 컨테이너의 포트로 생각하면 됩니다.

생성된 로드밸런서를 정보를 확인하거나 "서비스 및 수신" 메뉴를 클릭하면 엔트포인트 정보를 확인할 수 있습니다.

아래는 생성된 부하분산기(로드 밸런서) 정보입니다.

아래는 서비스 및 수신" 메뉴를 클릭하면 나타나는 화면입니다.

위에서 확인한 엔트포인트를 브라우저로 접속하면 nginx 초기 화면이 나타납니다.

** node와 pod **

2. Standard 클러스터 만들기

Kubernetes Engine 의 "클러스터" 메뉴를 클릭한 후 나타난 화면에서 [만들기] 버튼을 클릭합니다.

아래와 같이 Standard와 Autopilot 모드가 나타나는데 원하는 클러스터 모드를 선택합니다.

Standard 모드로 클러스터를 만들기 위해 "GKE Standard"의 [구성] 버튼을 클릭합니다.

클러스터 이름과 리전을 지정하고 [만들기] 버튼을 클릭하여 Standard 클러스터를 생성합니다.

클러스터가 생성되면 아래 화면과 같이 노드수와 총vCPU, 총메모리 값을 확인할 수 있습니다.

nginx 배포 테스트를 하기 위해 아래 내용들을 수행합니다.

작업부하

클러스터 화면의 상단에 [배포]를 클릭하거나 Kubernetes Engine 하위의 "작업 부하" 메뉴를 클릭한 후 [배포]를 클릭합니다.

아래 화면이 나타나면 [계속] 버튼을 클릭합니다.

아래의 컨테이너 구성화면에서 클러스트 항목에서 위에서 생성한 standard 클러스터(standard-cluster-1)를 선택합니다. 

[배포]를 클릭합니다.

외부와 통신하기 위해 [노출] 버튼을 클릭합니다. 아래 화면이 나타나면 "포트1"에 서비스 포트 입력, "대상포트1"에는 컨테이너의 포트를 입력합니다. 쉽게 말해 "포트1"은 node의 포트이고 "대상포트1"은 컨테이너의 포트로 생각하면 됩니다. 서비스유형은 "부하분산기"를 선택합니다.

생성된 로드밸런서를 정보를 확인하거나 "서비스 및 수신" 메뉴를 클릭하면 엔트포인트 정보를 확인할 수 있습니다.

아래는 생성된 부하분산기(로드 밸런서) 정보입니다.

아래는 서비스 및 수신" 메뉴를 클릭하면 나타나는 화면입니다.

위에서 확인한 엔트포인트를 브라우저로 접속하면 nginx 초기 화면이 나타납니다.

작업환경

- Window10 WSL2(Ubuntu 20.04.3 LTS )

- kubernets client : v1.22.5

- kubernets server : v1.23.1

- podman : 3.4.2

minikube start

minikube는 Kubernetes용으로 쉽게 배우고 개발할 수 있도록 하는 데 중점을 둔 로컬 Kubernetes입니다.

Docker 컨테이너 또는 가상 머신 환경만 있으면 Kubernetes가 단일 명령으로 실행됩니다.(minikube start)

필요한 것

• 2 CPU 이상
• 2GB의 여유 메모리
• 20GB의 디스크 여유 공간
• 인터넷 연결
• 컨테이너 또는 가상 머신 관리자(예: Docker , Hyperkit , Hyper-V , KVM , Parallels , Podman , VirtualBox 또는 VMware Fusion/Workstation) 본 문서에서는 Podman 사용

1설치

본 문서는 wsl2 에 설치된 linux 에서 실행했습니다.

바이너리를 다운로드하여 x86-64 Linux 에 최신 minikube 안정 릴리스 를 설치합니다.

curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
sudo install minikube-linux-amd64 /usr/local/bin/minikube

바이너리를 검증한다. (선택 사항)

kubectl 체크섬(checksum) 파일을 다운로드한다.

curl -LO "https://dl.k8s.io/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl.sha256"

kubectl 바이너리를 체크섬 파일을 통해 검증한다.

echo "$(<kubectl.sha256) kubectl" | sha256sum --check

kubectl: FAILED
sha256sum: WARNING: 1 computed checksum did NOT match

검증이 성공한다면, 출력은 다음과 같다.

kubectl: OK

참고: 동일한 버전의 바이너리와 체크섬을 다운로드한다.

kubectl 설치

chmod +x kubectl
mkdir -p ~/.local/bin/kubectl
mv ./kubectl ~/.local/bin/kubectl
# 그리고 ~/.local/bin/kubectl을 $PATH에 추가

sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl

설치한 버전이 최신인지 확인한다.

kubectl version --client

기본 패키지 관리 도구를 사용하여 

기본 패키지 관리 도구를 사용하여 설치

GKE란

GKE(Google Kubernetes Engine) : Kubernetes를 자동으로 배포, 확장, 관리할 수 있습니다.

GKE 사용하기

구글 메뉴에서 "Kubernetes Engine"을 클릭합니다.

아래 화면에서 [사용] 버튼을 클릭합니다.

쿠버네티스 클러스터 생성하기

GKE Standard 구성하기

GKE Standard와 GKE Autopilot 두 가지 구성방식이 있으며, 본 문서에서는 GKE Standard 방식으로 구성합니다.

• 표준 : 직접확장 구성, 노드를 직접관리, 노드당 결제
• 오토파일럿 : 코드로드를 기준으로 자동확장, Google에서 노드를 관리, pod당 결제

클러스터 기본사항

클러스터 이름 및 영역을 설정한 후 만들기 버튼을 클릭합니다. 본 문서에스는 클러스터이름으로 cluster-1 을 사용하고 클러스터 위치유형은 영역으로 설정하고 asia-northeaset3-a 를 사용합니다.

아래와 같이 정삭적으로 생성된 것을 확인할 수 있다.

생성된 클러스트를 클릭한 후 클러스터 메뉴에서 [연결] 버튼을 클릭합니다.

아래와 같이 클러스터에 연결할 수 있는 화면이 나타나는데 "CLOUD SHELL에서 실행"을 클릭합니다.

브라우저에서 클라우드 쉘이 실행되는데 쉘이 실행되면 gcloud 명령어가 입력되어 있는데 쿠버네티스 클러스터에 대한 인증을 받는 부분이므로 엔터키를 눌러 실행시켜줍니다.

아래는 gcloud 명령어 예입니다.  프로젝트명과 region은 각자의 환경에 따라 상이합니다.

$ gcloud container clusters get-credentials cluster-1 --zone asia-northeast3-a --project advance-casing
Fetching cluster endpoint and auth data.
kubeconfig entry generated for cluster-1.

kuberctl 명령어로 쿠버네티스 클러스터의 노드를 조회합니다. 여기서 나오는 모든 노드들은 워커 노드들입니다다. 관리를 위한 마스터 노드는 사용자에게 보여주지 않습니다.

$ kubectl get nodes
NAME                                       STATUS   ROLES    AGE   VERSION
gke-cluster-1-default-pool-87040182-2nzb   Ready    <none>   16m   v1.22.4-gke.1501
gke-cluster-1-default-pool-87040182-4r9w   Ready    <none>   16m   v1.22.4-gke.1501
gke-cluster-1-default-pool-87040182-tj88   Ready    <none>   16m   v1.22.4-gke.1501

쿠버네티스에 nginx 컨테이너를 배포하고 외부에 로드밸런서를 구성해 봅니다.

$ kubectl create deploy nx --image=nginx # 포드와 컨테이너 생성
deployment.apps/nx created

$ kubectl expose deploy nx --type=LoadBalancer --port=80 # 외부 로드밸런서와 서비스 구성 
service/nx exposed

$ kubectl scale deploy nx --replicas=3 # nginx 컨테이너를 3개로 증가
deployment.apps/nx scaled

svc와 pod를 조회하면 다음과 같이  34.64.108.79 처럼 공인 IP를 확인할 수 있다. pod는 컨테이너를 관리하는 그룹으로 3개가 구성되고 있음을 확인할 수 있다. 공인 IP로 접근하면 해당 포드들로 접속할 수 있다.

$ kubectl get svc,pod
NAME                 TYPE           CLUSTER-IP     EXTERNAL-IP    PORT(S)        AGE
service/kubernetes   ClusterIP      10.36.0.1      <none>         443/TCP        43m
service/nx           LoadBalancer   10.36.12.246   34.64.108.79   80:30877/TCP   87s

NAME                      READY   STATUS    RESTARTS   AGE
pod/nx-5d8c979794-cd22x   1/1     Running   0          70s
pod/nx-5d8c979794-kt4vs   1/1     Running   0          70s
pod/nx-5d8c979794-pcgc5   1/1     Running   0          108s

브라우저에 위에서 확인한 공인 IP( 34.64.108.79)를 입력하면 "Welcome to nginx!" 라는 문구를 볼 수 있습니다.

클러스터 삭제

학습용이나 테스트용으로 구성했을 경우 클러스터를 삭제합니다.

 

Pod란?

쿠버네티스는 컨테이너를 개별적으로 배포하는 것이 아니라 Pod라는 단위로 컨테이너를 묶어서 관리하게 됩니다. 하나의 파드는 다수의 컨테이너를 가지고 있을 수 있는데, 왜 개별적으로 하나씩 컨테이너를 배포하지 않고 여러 개의 컨테이너를 Pod단위로 묶어서 배포하게 될까요? 이와 같은 이유에는 두 가지 특징이 있습니다.

파드는 쿠버네티스 플랫폼 상에서 최소 단위입니다. 쿠버네티스에서 배포를 생성할 때, 그 배포는 컨테이너 내부에서 컨테이너와 함께 파드를 생성합니다.

1. Pod 내의 컨테이너는 IP와 Port를 공유합니다.
   즉 두개 이상의 컨테이너가 하나의 파드를 통해 배포되었을 때 localhost로 통신이 가능합니다.
2. Pod내에 배포된 컨테이너 간에는 디스크 볼륨을 공유할 수 있습니다.
   최근 애플리케이션들은 실행할 때 애플리케이션만 올라가는 것이 아니라 로그 수집기와 같은 다양한 솔루션이 함께 배포되는 경우가 많습니다.
   
   특히 로그수집기 같은 경우에는 애플리케이션의 로그 파일을 읽어서 수집하기 때문에 애플리케이션과 로그 수집기를 다른 컨테이너로 배포하게 될 경우, 일반적으로는 컨테이너에 의해서 독립적인 환경으로 파일 시스템이 분리되기 때문에 로그 수집기가 애플리케이션에 배포된 컨테이너의 로그 파일을 읽는 것이 불가능하지만, 쿠버네티스의 경우 하나의 파드 안에서 컨테이너끼리 볼륨을 공유할 수 있기 때문에 다른 컨테이너의 파일을 읽어올 수 있습니다.

3. 컨테이너 이미지 버전 또는 사용할 특정 포트와 같이 각 컨테이너가 동작하는 방식에 대한 정보

아래의 이미지로 좀 더 자세히 살펴보도록 하겠습니다.

아래의 이미지는 worker node를 나타낸 이미지입니다. 노드의 구조를 살펴보면 node안에 여러 개의 pod가 있고, 그 안에 실질적으로 서비스를 수행하는 작은 container들이 동작하게 됩니다. 이때 애플리케이션과 볼륨이 하나의 pod안에 있음으로써 컨테이너끼리 볼륨을 공유할 수 있게 됩니다.

그 외에도 kubelet와 docker가 있는데, kubelet는 node에서 pod와 container를 관리하는 역할을 하고 docker는 k8s에서 기본적으로 사용하는 container runtime입니다.

노드