[90DaysOfDevOps] Day 49~52

클라우드/DevOps

[90DaysOfDevOps] Day 49~52 - Kubernetes

dayeonsheep 2024. 3. 12. 00:51

Main reference

https://github.com/MichaelCade/90DaysOfDevOps/blob/main/2022/

Day 49

< Kubernetes 개념 >

들어가며...

컨테이너는 scale과 오케스트레이션만으로는 부족
kuburnetes를 사용하면 애플리케이션과 서비스의 부하에 따라 자동화된 방식으로 확장 및 축소 용이
데브옵스 관점에서 볼 때 Kubernetes는 애플리케이션을 실행하기 위한 또 다른 옵션일 뿐이며, 베어메탈*, 가상화 및 대부분의 클라우드 기반 서비스도 이해해야 함

+ 베어메탈?

Bare Metal

가상화 기술을 사용하지 않고 물리적으로 분리된 하드웨어 컴퓨팅 자원을 단독으로 할당받아 사용할 수 있는 클라우드 컴퓨팅 서비스
- 하드웨어 상에 어떤 소프트웨어도 설치되어 있지 않은 상태
- 가상화를 위한 하이퍼바이저 OS 없이 물리 서버를 그대로 제공하는 것
- 하드웨어에 대한 직접 제어 및 OS 설정까지 가능, 하드웨어를 구매할 수 있는 상품을 의미하기도 함

컨테이너 오케스트레이션이란?

k8s는 기술인 반면, 컨테이너 오케스트레이션은 기술 이면의 개념 또는 프로세스
대규모 애플리케이션을 배포할 수 있도록 컨테이너의 네트워킹 및 관리를 자동화하는 프로세스
컨테이너의 프로비저닝, 배포, 네트워킹, 확장, 가용성 및 라이프사이클 관리를 자동화

Kubernetes란?

컨테이너화된 워크로드와 서비스를 관리하기 위한 이식 가능하고 확장 가능한 오픈소스 플랫폼
선언적 구성과 자동화를 모두 용이하게 함
분산 시스템을 탄력적으로 실행할 수 있는 프레임워크 제공

k8s의 이점

Services discovery 및 로드 밸런싱 : k8s는 DNS 이름 또는 IP 주소를 사용하여 컨테이너 노출할 수 있음 -> 컨테이너에 대한 트래픽이 많을 경우, k8s는 네트워크 트래픽을 로드 밸런싱하고 배포가 안정적으로 이루어지도록 함
스토리지 오케스트레이션 : 로컬 스토리지, 퍼블릭 클라우드 제공자 등 원하는 스토리지 시스템을 자동으로 마운트* 가능
- 스토리지를 마운트한다는 것 = 파일 시스템의 특정 디렉토리를 물리적인 스토리지 장치에 연결하는 작업
- 주로 네트워크 파일 시스템(NFS), 로컬 디스크, 클라우드 스토리지 등과 같은 다양한 형태의 스토리지와 연결됨
- 마운트된 스토리지를 사용하면 파일 시스템 간의 데이터 공유, 데이터 백업 및 복구, 파일 시스템 용량 확장 등과 같은 다양한 용도로 활용될 수 있음
롤아웃 및 롤백 자동화 (새로운 소프트웨어 버전이나 업데이트를 서비스나 시스템에 배포하는 과정 & 이전버전으로 되돌리는 과정) : 배포된 컨테이너에 대해 원하는 상태를 설명할 수 있음, 제어된 속도로 실제 상태를 원하는 상태로 변경 가능
- ex. 배포를 위한 새 컨테이너 생성하고, 기존 컨테이너 제거하고, 모든 리소스를 새 컨테이너에 적용하도록 k8s를 자동화하기 가능
bin 패킹 자동화 : 컨테이너화된 작업을 실행하는 데 사용할 수 있는 노드 클러스트를 k8s에 제공하고 -> 각 컨테이너에 필요한 CPU와 메모리(RAM)의 양을 k8s에 알려주면 -> k8s는 리소스를 최대한 활용하기 위해 컨테이너를 노드에 맞출 수 있음.
자가 복구 : 장애 발생한 컨테이너 재시작 & 교체 & 사용자 정의 상태 확인에 응답안하는 컨테이너 죽이기 & 제공 준비 전까지 클라이언트에게 알리지 않음
보안 및 구성 관리 : 민감한 보안 정보 저장 관리, 노출하지 않고 애플리케이션 구성을 배포하고 업데이트 가능

k8s의 역할

호스트를 하나의 대상으로 묶어 클러스터로 관리
스케줄러를 통해 컨테이너를 노드 간에 배포하는 스케줄 관리
컨테이너의 위치를 파악하고 클라이언트 요청을 컨테이너에 분산하는 Services discover
요청된 워크로드에 적합한 수의 노드와 컨테이너를 사용할 수 있도록 보장하도록 복제
건강하지 않은 컨테이너와 노드를 감지하고 교체하는 상태관리

https://kubernetes.io/docs/concepts/overview/

Overview

Kubernetes is a portable, extensible, open source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools

kubernetes.io

주요 K8S 구성요소

k8s는...

VM 또는 물리적 머신과 같은 워커 머신의 모음인 노드 클러스터에서 컨테이너화된 앱의 라이프 사이클 관리할 수 있음
앱 실행시 여러 리소스 필요한데 k8s 사용하면 이러한 리소스를 앱에 추가할 수 있음. 앱에 필요한 인프라 리소스는 선언적으로 관리됨. (선언적으로 관리된다는 게 어떤 의미? -> 시스템의 원하는 상태를 명시하고 이를 시스템에 전달함으로써 시스템이 해당 상태를 달성하도록 하는 방식을 의미)

'선언적 모델' - 사용자가 원하는 상태를 제공하면 k8s가 이를 실현

if 사용자가 인스턴스 5개 필요하면, 사용자가 직접 시작하는게 아니라 k8s한테 알려주면 자동으로 상태 조정함.

그래서 구성요소 구성도 미리보기

1. 노드

A. 컨트롤 플레인 노드

모든 k8s 클러스터에 필요함.
컨트롤 플레인의 구성 요소는 클러스터에 대한 전역 결정을 내리고 클러스터 이벤트를 감지 및 응답함.
k8s 노드는 컨트롤 플레인에 의해 관리됨
고가용성으로 만들 수 있는 컨트롤 플레인에는 워커 노드와 비교하여 몇 가지 고유한 역할이 포함됨

B. 워커 노드 (각 Node 1, 2, 3)

k8s 워크로드를 실행하는 워커 머신
물리적(베어메탈) 머신이거나 가상머신 일 수 있음
각 노드는 하나 이상의 pod을 호스트 할 수 있음.

+ 다른 노드유형 (엣지노드, 마스터노드, GPU 노드 등이 있음)

+ pod이란? (글 밑에서 더 자세한 설명...)

Pod은 Kubernetes에서 가장 작은 배포 단위이며, 하나 이상의 컨테이너 그룹.

일반적으로 하나의 Pod 안에는 여러 개의 컨테이너가 함께 실행됨

이러한 컨테이너는 동일한 네트워크 네임스페이스와 파일 시스템을 공유하며, 같은 리소스를 사용

1.1. Kubelet

클러스터의 각 노드에서 실행되는 에이전트
컨테이너가 pod에서 실행되고 있는지 확인
다양한 메커니즘을 통해 제공되는 일련의 PodSpec*을 가져와서 PodSpec에 설명된 컨테이너가 실행 중이고 정상인지 확인함
kubelet은 k8s가 생성하지 않은 컨테이너는 관리하지 않음

*스펙에는 어떤게 포함되나?

PodSpec은 Pod의 원하는 상태를 정의하고 Kubernetes 시스템에 전달하여 Pod을 생성하고 구성하는 데 사용됨

1. **컨테이너 선언**: Pod 내에서 실행될 하나 이상의 컨테이너를 정의합니다. 각 컨테이너는 이미지, 이름, 환경 변수, 포트 등의 구성 옵션을 포함할 수 있습니다.

2. **볼륨 마운트**: Pod 내의 각 컨테이너가 사용할 수 있는 볼륨을 정의합니다. 이는 파일 시스템 또는 네트워크 저장소와 같은 다양한 종류의 볼륨을 마운트할 수 있습니다.

3. **리소스 요청 및 제한**: 각 컨테이너에 대한 CPU 및 메모리 요청과 제한을 정의하여 클러스터의 리소스 관리를 위한 정보를 제공합니다.

4. **환경 변수 및 시크릿**: Pod 내의 컨테이너에 전달될 환경 변수 및 시크릿을 정의합니다. 이를 통해 컨테이너가 실행되는 환경을 구성하고 보안을 유지할 수 있습니다.

5. **라이프사이클 이벤트**: Pod의 생성, 시작, 중지 등과 같은 라이프사이클 이벤트에 대한 훅을 정의합니다. 이를 통해 Pod이 실행되는 동안 필요한 작업을 수행할 수 있습니다.

PodSpec은 YAML 또는 JSON 형식으로 작성되며, 이를 사용하여 Kubernetes에게 Pod을 생성하고 구성하는 방법을 정의PodSpec을 사용하면 사용자는 Pod의 원하는 상태를 명시적으로 정의하여 Kubernetes가 이를 관리하고 유지할 수 있음

1.2. Kube-proxy

클러스터의 각 노드에서 실행되는 네트워크 프록시(프록시 = 클라이언트와 서버사이에서 중간 역할을 하는 서버)
k8s 서비스 개념의 일부를 구현
노드에서 네트워크 규칙을 유지 관리
클러스터 내부 또는 외부의 네트워크 세션에서 pod로의 네트워크 통신을 허용
if 운영체제 패킷 필터링 계층이 있고 사용가능하면 kube-proxy는 이를 사용함. else kube-proxy는 트래픽 자체를 전달

1.3. Container Runtime

컨테이너 실행을 담당하는 SW
k8s는 여러 컨테이너 런타임을 지원함(Docker, containerd, CRI-O, k8s Container Runtime Interface (CRI))

2. 클러스터

노드의 그룹 (노드 = 물리적 머신 or 가상 머신)
각 노드에는 컨테이너 런타임(Docker등)이 있으며 마스터 컨트롤러의 명령을 받는 에이전트인 kubelet서비스와 다른 구성 요소에서 pod에 대한 연결을 프록시하는 데 사용되는 프록시도 실행

2.1. Kube API 서버

정보를 가져오거나 k8s클러스터로 정보를 푸시하기 위한 모든 통신이 이루어지는 곳
pod, 서비스, 응답 컨트롤러 등을 포함하는 API 오브젝트에 대한 데이터의 유효성을 검사하고 구성
REST 작업을 수행하고 다른 모든 구성 요소가 상호작용하는 클러스터의 공유상태에 대한 FE를 제공

2.2. 스케줄러

노드에 pod을 할당하는 컨트롤 플레인 프로세스
제약 조건과 사용 가능한 리소스에 따라 스케줄링 대기열에서 각 pod에 대해 유효한 배치가 되는 노드를 결정
그런 다음 유효한 노드의 순위를 매기고 pod을 적합한 노드에 바인딩 (바인딩 -> Pod을 특정 노드에 할당하는 과정)

2.3. 컨트롤러 매니저

k8s와 함께 제공되는 핵심 제어루프를 임베드하는 daemon(백그라운드에서 실행되는 프로그램 또는 서비스)
제어 루프 = 로보틱스 및 자동화 애플리케이션에서 시스템 상태를 조절하는 비종료 루프, (시스템이 원하는 상태를 유지하기 위해 지속적으로 상태를 검사하고 조정하는 과정)
API 서버를 통해 클러스터의 공유 상태를 감시하고 현재 상태를 원하는 상태로 이동시키기 위해 변경을 시도하는 제어 루프

2.4. etcd

모든 클러스터 데이터에 대한 k8s의 백업 저장소로 사용되는 일관되고 가용성이 높은 키 값 저장소

3. kubectl

Container Runtime Interface (CRI) 관점에서 관리하기 위해 있는 커맨드-라인도구
API와 상호작용
k8s 클러스터에 대해 명령을 실행할 수 있음
얘를 사용하여 애플리케이션을 배포하고, 클러스터 리소스를 검사 및 관리하고 로그 확인

4. Pods

논리적 애플리케이션을 구성하는 컨테이너 그룹
ex. NodeJS 컨테이너와 MySQL 컨테이너를 실행하는 웹 애플리케이션이 있으면, 두 컨테이너는 모두 단일 pod에 위치하게 됨
pod은 공통 데이터 볼륨을 공유할 수 있으며 동일한 네트워킹 네임스페이스도 공유
k8s는 pod를 식별하기 위해 레이블(이름-값)개념 사용

컨테이너의 볼륨, secret 및 구성 을 처리
임시적이라 죽을 경우 자동으로 재시작
ReplicationSet에 의해 수평적으로 확장될 때 복사되며, 각 pod은 동일한 컨테이너 코드를 실행
pod은 워커 노드에서 실행됨
pod은 마스터 컨트롤러* 에 의해 이동/변경될 수 있음

마스터 컨트롤러 - 컨트롤 플레인 - 클러스터의 관계가 헷갈려서 잠깐 정리

클러스터 ⊃ 마스터 노드 ⊃ 컨트롤 플레인 ⊃ 마스터 컨트롤러

- 클러스터 = 모든 노드 및 리소스의 집합, 하나 이상의 마스터 노드와 워커(노드)로 구성
- 마스터 노드에서 컨트롤 플레인 실행하고 클러스터의 전체 상태를 관리
- 컨트롤 플레인은 클러스터의 중앙 관리 및 제어를 담당하는 부분

4.1. 워크로드 관리 API들

최종적으로 애플리케이션은 Pod 내의 컨테이너로 실행됨,

개별 pod 관리의 어려움을

Kubernetes API를 사용하여 워크로드 객체를 생성하여 Pod보다 더 높은 추상화 수준을 나타내고,

Kubernetes 제어 플레인은 사용자가 정의한 워크로드 객체의 명세에 따라 자동으로 Pod 객체를 관리함

그 워크로드 관리를 위해 있는 API들은 아래와 같다~

4.1.1. Deployments

Pod를 따로 실행시킬 수도 있지만, 이런 경우 Pod가 죽으면 그냥 죽고 끝(재시작 안함) 그래서
Deployments는 Pod가 지속적으로 실행되게 만들 수 있음
현재 실행 중인 앱을 downtime 없이 업데이트하거나 Pod가 죽었을 때 재시작하는 전략을 지정할 수 있음

4.1.2. ReplicaSets

Deployments는 ReplicaSets을 생성할 수도 있고, ReplicaSets은 Deployments에 따라 pod를 생성하고 확장
ReplicaSets은 앱이 원하는 수의 pod를 갖도록 보장
Deployments, ReplicaSets, pod는 배타적이지는 않지만 그렇게 설계도 가능

4.1.3. StatefulSets

= 상태 저장 애플리케이션을 관리하는 데 사용되는 워크로드 API object

워크로드에 지속성을 제공하기 위해 스토리지 볼륨을 사용하려는 경우 솔루션의 일부로 StatefulSet를 사용할 수 있음
StatefulSets의 pod은 서로 호환되지 않음
각 pod에는 컨트롤러가 모든 스케줄링에 대해 유지하는 고유하고 영구적인 식별자가 있음

4.1.4. DaemonSets

연속 프로세스를 위한 것
노드당 하나의 pod을 실행
클러스터에 새로운 노드가 추가될 때마다 pod가 시작됨
모니터링 및 로그 수집과 같은 백그라운드 작업에 유용
각 pod에는 컨트롤러가 모든 스케줄링에 대해 유지하는 고유하고 영구적인 식별자가 있음

5. Services

= Service는 클러스터에서 하나 혹은 더 많은 pods을 실행시키고 있는 네트워크 애플리케이션을 노출하는(접속할 수 있게)하는 방법

pod에 액세스하기 위한 단일 엔드포인트
클러스터와 최종적으로 pod 목록으로 트래픽을 라우팅하는 통합된 방법
services를 사용하면 아무 영향 없이 pod을 올리고 내릴 수 있음

Day 50

< Kubernetes 플랫폼 선택하기 >

1. 베어 메탈 클러스터:
   - 물리적 서버에서 직접 Kubernetes 클러스터를 구축하는 옵션 (보통 바로 LinuxOS를 실행하는 옵션)
   - k8s 클러스터를 직접 구축 및 관리 해야한다는 것을 의미

2. 가상화:
   - 가상머신을 스핀업*(가상머신을 가동하는 것)하여 노드 역할을 하도록 한 다음 함께 클러스터링 할 수 있는 방법
   - 가상화의 기본 아키텍처-효율성 및 속도 활용 & 기존 spend를 활용할 수 있음
   - ex) VMware, Microsoft Hyper-V

3. 로컬 데스크톱 옵션:
   - 개발자가 개인적으로 로컬 환경에서 Kubernetes 클러스터를 실행하는 방법
   - Minikube와 같은 도구를 사용하여 테스트 및 개발에 적합

4. Kubernetes 관리형 서비스:

가상화는 로컬에서 하이퍼바이저를 통해 달성할 수 있지만 퍼블릭 클라우드의 가상 머신을 활용하여 노드 역할을 할 수도 있다

그래서 k8s Managed Service는 ~
- 대규모 스케일 뿐만 아니라 최종 사용자로부터 제어 플레인을 제거하는 Managed Service Provider에서 제공하는 서비스

- Amazon EKS, Microsoft AKS, Google Kubernetes Engine(GKE) 등

Day 51

< Kubernetes 클러스터 배포하기 >

Minikube로 실습

- Kubernetes 클러스터를 배포하고 관리하는 데 사용되는 오픈소스 도구

- Minikube를 사용하면 로컬 컴퓨터에서 단일 노드 Kubernetes 클러스터를 실행하여 애플리케이션 개발, 테스트 및 배포를 쉽게 할 수 있으며, 단일 머신에서 다중 노드 Kubernetes 환경을 시뮬레이션하여 다양한 Kubernetes 기능 및 구성을 실험할 수 있음

- OS 상관없음

brew install minikube

curl -sLS https://get.arkade.dev | sh

arkade get
arkade get minikube

minikube start
minikube addons list

arkade get kubectl

순서대로 arkade와 minikube를 다운받아주고~

중간에 addons list 확인도 함 (애드온 = 프로그램 보강하기 위한 추가 프로그램)

kubectl 추가설명

kubectl은 Kubernetes 클러스터와 상호 작용하는 데 사용되거나 상호 작용할 수 있게 해주는 cli(Command-Line Interface)
Minikube 클러스터 상호작용도 되고, 퍼블릭 클라우드 전반의 엔터프라이즈 클러스터와 상호작용하는 데 kubectl을 사용할 수 있음
애플리케이션을 배포하고 클러스터 리소스를 검사 및 관리하기 위해 kubectl을 사용
컨트롤 플레인 노드에 있는 API 서버와 상호작용

Day 52

< 멀티노드 Kubernetes 클러스터 설정하기 >

Vagrant로 멀티노드 Kubernetes 클러스터 설정하기

Vagrant

Vagrant는 가상 머신의 라이프사이클을 관리하는 CLI 유틸리티
vSphere, Hyper-v, Virtual Box, Docker 등 다양한 플랫폼에서 가상 머신을 스핀업 및 스핀다운하는 데 Vagrant를 사용

$ arkade get vagrant 하면 다운이 된다고 했지만

안되길래

직접 사이트 들어가서 찾은 brew 명령어로 다운받아줬다

brew tap hashicorp/tap
brew install hashicorp/tap/hashicorp-vagrant

하고 $ vagrant up

많은 에러가 나길래 이런저런 패키지 설정을 바꾸어줬지만 안되었고,

해결책은 vagrant init한다음에 vagant up 해줬더니 잘 실행이... 되었던 것 같다

그리고 기존 Vagrnatfile은 아래와 같았는데

NUM_WORKER_NODES=2
IP_NW="10.0.0."
IP_START=10

Vagrant.configure("2") do |config|
    config.vm.provision "shell", inline: <<-SHELL
        apt-get update -y
        echo "$IP_NW$((IP_START))  master-node" >> /etc/hosts
        echo "$IP_NW$((IP_START+1))  worker-node01" >> /etc/hosts
        echo "$IP_NW$((IP_START+2))  worker-node02" >> /etc/hosts
    SHELL
    config.vm.box = "bento/ubuntu-21.10"
    config.vm.box_check_update = true

    config.vm.define "master" do |master|
      master.vm.hostname = "master-node"
      master.vm.network "private_network", ip: IP_NW + "#{IP_START}"
      master.vm.provider "virtualbox" do |vb|
          vb.memory = 4048
          vb.cpus = 2
          vb.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]
      end
      master.vm.provision "shell", path: "scripts/common.sh"
      master.vm.provision "shell", path: "scripts/master.sh"
    end

    (1..NUM_WORKER_NODES).each do |i|
      config.vm.define "node0#{i}" do |node|
        node.vm.hostname = "worker-node0#{i}"
        node.vm.network "private_network", ip: IP_NW + "#{IP_START + i}"
        node.vm.provider "virtualbox" do |vb|
            vb.memory = 2048
            vb.cpus = 1
            vb.customize ["modifyvm", :id, "--natdnshostresolver1", "on"]
        end
        node.vm.provision "shell", path: "scripts/common.sh"
        node.vm.provision "shell", path: "scripts/node.sh"
      end
    end
  end

윈도우 기반이라 그런지 kubectl get nodes 했을 때 3노드로 구성되는 클러스터가 안 뜬다

kubectl get nodes 했을 때

master

node01

node02가 등장해야 하는데 안됨

그래서 이 코드로 바꿔봤다

Vagrant.configure("2") do |config|
  config.vm.boot_timeout = 3000

  config.vm.define "master" do |master|
    master.vm.box = "ubuntu/jammy64"
    master.vm.network "private_network", ip: "192.168.56.10"
    master.vm.hostname = "master"

    master.vm.provider "virtualbox" do |v|
      v.memory = 4096
      v.cpus = 4
    end

    master.vm.provision "0", type: "shell", preserve_order: true, privileged: true, inline: <<-EOC
cat <<-'EOF' >/etc/modules-load.d/kubernetes.conf
br_netfilter
EOF

sudo modprobe br_netfilter

cat <<-'EOF' >/etc/sysctl.d/kubernetes.conf
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward = 1
EOF

sudo sysctl --system

sudo apt update
sudo apt install -y curl gnupg2 software-properties-common apt-transport-https ca-certificates

sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmour -o /etc/apt/trusted.gpg.d/docker.gpg
sudo add-apt-repository -y "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"

sudo apt update
sudo apt install -y containerd.io

containerd config default | sudo tee /etc/containerd/config.toml >/dev/null 2>&1
sudo sed -i 's/SystemdCgroup \= false/SystemdCgroup \= true/g' /etc/containerd/config.toml

sudo systemctl restart containerd
sudo systemctl enable containerd

cat <<-'EOF' >/etc/default/kubelet
KUBELET_EXTRA_ARGS=--node-ip=192.168.56.10
EOF

curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.28/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.28/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl

OUTPUT_FILE=/vagrant/join.sh
rm -rf $OUTPUT_FILE
rm -rf /vagrant/.kube
sudo kubeadm init --pod-network-cidr=10.244.0.0/16 --control-plane-endpoint=192.168.56.10 --apiserver-advertise-address=192.168.56.10
sudo kubeadm token create --print-join-command > $OUTPUT_FILE
chmod +x $OUTPUT_FILE

mkdir -p $HOME/.kube
sudo cp /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
cp -R $HOME/.kube /vagrant/.kube
cp -R $HOME/.kube /home/vagrant/.kube
sudo chown -R vagrant:vagrant /home/vagrant/.kube
kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml
kubectl completion bash >/etc/bash_completion.d/kubectl
echo 'alias k=kubectl' >>/home/vagrant/.bashrc
    EOC
  end

  (1..3).each do |i|
    config.vm.define "worker#{i}" do |worker|
      worker.vm.box = "ubuntu/jammy64"
      worker.vm.network "private_network", ip: "192.168.56.1#{i}"
      worker.vm.hostname = "worker#{i}"

      worker.vm.provider "virtualbox" do |v|
        v.memory = 2048
        v.cpus = 2
      end

      worker.vm.provision "0", type: "shell", preserve_order: true, privileged: true, inline: <<-EOC
cat <<-'EOF' >/etc/modules-load.d/kubernetes.conf
br_netfilter
EOF

sudo modprobe br_netfilter

cat <<-'EOF' >/etc/sysctl.d/kubernetes.conf
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward = 1
EOF

sudo sysctl --system

sudo apt update
sudo apt install -y curl gnupg2 software-properties-common apt-transport-https ca-certificates

sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmour -o /etc/apt/trusted.gpg.d/docker.gpg
sudo add-apt-repository -y "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"

sudo apt update
sudo apt install -y containerd.io

containerd config default | sudo tee /etc/containerd/config.toml >/dev/null 2>&1
sudo sed -i 's/SystemdCgroup \= false/SystemdCgroup \= true/g' /etc/containerd/config.toml

sudo systemctl restart containerd
sudo systemctl enable containerd

cat <<-'EOF' >/etc/default/kubelet
KUBELET_EXTRA_ARGS=--node-ip=192.168.56.1#{i}
EOF

curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.28/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.28/deb/ /' | sudo tee /etc/apt/sources.list.d/kubernetes.list
sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl
      EOC
    end
  end
end

얘는 worker#{i} 이름을 가진 노드들이 생성되는 코드다

바꿔봤더니

kubectl이 Kubernetes API 서버에 연결하지 못하는 에러가 발생하는데

해볼 방법 1.k8s API 서버 실행중인지 확인 2.포트넘버 확인 3. ~/.kube/config 확인 인데

저 config 파일... kube 파일... 이

난 뭐가 이상한 것 같다

(추후 트러블슈팅글로 따로 쓰겟음)

클러스터 외부에서 kubectl 액세스가 발생하여 해당 kube apiserver에 도달하는 것으로 표시되어 있지만,
실제로는 vagrant 프로비저닝의 일부로 각 노드 내에서 클러스터에 액세스할 수 있도록 각 노드에 kubectl을 배포하고 있음

배포의 일부로 3개의 스크립트를 호출하는 vagrant 파일을 보면 클러스터가 실제로 생성되는 곳이라는 것을 알 수 있음

완료되면 터미널에서 노드 중 하나에 vagrant ssh master로 접속하면 액세스할 수 있음(기본 사용자 이름/비밀번호- vagrant/vagrant)
원하는 경우 vagrant ssh node01 및 vagrant ssh node02를 사용하여 작업자 노드에 액세스할 수도 있음

Kubernetes 클러스터에 액세스

기본적으로, Kubernetes CLI 클라이언트(kubectl)는 엔드포인트 및 자격 증명과 같은 Kubernetes 클러스터 세부 정보를 저장하기 위해 C:\Users\username.kube\config를 사용, 배포했으면 이 위치에서 확인 가능(window기준)
클러스터에서 kubeconfig 파일을 가져와 복사하고 $HOME/.kube/config 위치로 이동
$ kubectl cluster-info와 $ kubectl get nodes를 실행하여 클러스터에 액세스할 수 있는지 확인가능

이렇게 하면 윈도우 머신에서 연결 및 제어가 가능할 뿐만 아니라 윈도우 머신에서 특정 서비스에 액세스하기 위해 포트 포워딩을 수행할 수 있음

+ mac 에서 vagrant 실습을 진행해보고 싶은 사람들을 위한 가이드추천

저작자표시 비영리 변경금지