Minikube 실습하기

효율적인 쿠버네티스 클러스터 관리를 위한 kubectlCLI 환경 최적화

## Xcode 라이선스 동의
$ sudo xcodebuild -license accept

##  bash 설치 
$ brew install bash

## bash 버전 확인 
$ /bin/bash --version 
### GNU bash, version 3.2.57(1)-release (arm64-apple-darwin22)
### Copyright (C) 2007 Free Software Foundation, Inc.

## bash 위치 확인
$ which -a bash
### /opt/homebrew/bin/bash
### /bin/bash


# Set default shell
sudo su
echo "/opt/homebrew/bin/bash" >> /etc/shells
exit 

kubectl 자동완성 등록하기

brew install bash-completion@2
export BASH_COMPLETION_COMPAT_DIR="/opt/homebrew/etc/bash_completion.d"
kubectl completion bash >/opt/homebrew/etc/bash_completion.d/kubectl
echo 'export BASH_COMPLETION_COMPAT_DIR="/opt/homebrew/etc/bash_completion.d"'
echo 'alias k=kubectl' >>~/.bash_profile
echo 'complete -F __start_kubectl k' >>~/.bash_profile

cat ~/.zshrc

# >>> conda initialize >>>
# !! Contents within this block are managed by 'conda init' !!
__conda_setup="$('/Users/jeong-yoon/anaconda3/bin/conda' 'shell.zsh' 'hook' 2> /dev/null)"
if [ $? -eq 0 ]; then
    eval "$__conda_setup"
else
    if [ -f "/Users/jeong-yoon/anaconda3/etc/profile.d/conda.sh" ]; then
        . "/Users/jeong-yoon/anaconda3/etc/profile.d/conda.sh"
    else
        export PATH="/Users/jeong-yoon/anaconda3/bin:$PATH"
    fi
fi
unset __conda_setup
# <<< conda initialize <<<
# /Library/Frameworks/Python.framework/Versions/3.11/bin/python3
export PATH=/opt/homebrew/bin:$PATH
JAVA_HOME=/Library/Java/JavaVirtualMachines/zulu-11.jdk/Contents/Home
PATH=$PATH:$JAVA_HOME/bin
export JAVA_HOME
export PATH
# export PATH="/usr/local/opt/openjdk@17/bin:$PATH"

Kube-ctx(컨텍스트), kube-ns(네임스페이스), kube-ps1(프롬프트)

krew 설치

• git 설치
• 명령어 실행

(
  set -x; cd "$(mktemp -d)" &&
  OS="$(uname | tr '[:upper:]' '[:lower:]')" &&
  ARCH="$(uname -m | sed -e 's/x86_64/amd64/' -e 's/\(arm\)\(64\)\?.*/\1\2/' -e 's/aarch64$/arm64/')" &&
  KREW="krew-${OS}_${ARCH}" &&
  curl -fsSLO "https://github.com/kubernetes-sigs/krew/releases/latest/download/${KREW}.tar.gz" &&
  tar zxvf "${KREW}.tar.gz" &&
  ./"${KREW}" install krew
)

+-zsh:16> mktemp -d
+-zsh:16> cd /var/folders/sr/_jwdzn1j6jxgr13g20ybngc40000gn/T/tmp.SDH9XT0A
+-zsh:17> OS=+-zsh:17> uname
+-zsh:17> OS=+-zsh:17> tr '[:upper:]' '[:lower:]'
+-zsh:17> OS=darwin
+-zsh:18> ARCH=+-zsh:18> uname -m
+-zsh:18> ARCH=+-zsh:18> sed -e s/x86_64/amd64/ -e 's/(arm)(64)\?./\1\2/' -e 's/aarch64$/arm64/'
+-zsh:18> ARCH=arm64
+-zsh:19> KREW=krew-darwin_arm64
+-zsh:20> curl -fsSLO https://github.com/kubernetes-sigs/krew/releases/latest/download/krew-darwin_arm64.tar.gz
+-zsh:21> tar zxvf krew-darwin_arm64.tar.gz
x ./LICENSE
x ./krew-darwin_arm64
+-zsh:22> ./krew-darwin_arm64 install krew
Adding "default" plugin index from https://github.com/kubernetes-sigs/krew-index.git.
Updated the local copy of plugin index.
Installing plugin: krew
Installed plugin: krew
\
| Use this plugin:
| kubectl krew
| Documentation:
| https://krew.sigs.k8s.io/
| Caveats:
| \
| | krew is now installed! To start using kubectl plugins, you need to add
| | krew's installation directory to your PATH:
| |
| | macOS/Linux:
| | - Add the following to your ~/.bashrc or ~/.zshrc:
| | export PATH="{KREW_ROOT:-HOME/.krew}/bin:$PATH"
| | - Restart your shell.
| |
| | * Windows: Add %USERPROFILE%.krew\bin to your PATH environment variable
| |
| | To list krew commands and to get help, run:
| | $ kubectl krew
| | For a full list of available plugins, run:
| | $ kubectl krew search
| |
| | You can find documentation at
| | https://krew.sigs.k8s.io/docs/user-guide/quickstart/.
| /
/

• 환경변수 등록

export PATH="${KREW_ROOT:-$HOME/.krew}/bin:$PATH"

• 설치 확인

kubectl krew

• k 사용이 안될 때 설치 확인

echo "export PATH=\$PATH:\$HOME/.krew/bin" >> ~/.zshrc
source ~/.zshrc

• Krew 설치하기

set -x; cd "$(mktemp -d)" &&
curl -fsSLO "https://github.com/kubernetes-sigs/krew/releases/latest/download/krew.tar.gz" &&
tar zxvf krew.tar.gz &&
KREW=./krew-"$(uname | tr '[:upper:]' '[:lower:]')_amd64" &&
"$KREW" install krew

kube-ctx 설치

$ k krew install ctx

# 로컬 호스트에 등록되어 있는 클러스터 목록 확인
$ k ctx 

# 해당 클러스터로 변경 
$ k ctx k8s-demo

Kube-ns

$ k krew install ns

# 현재 클러스터의 전체 네임스페이스 현황 출력 
$ k ns

Kubectl 명령어로 익히는 쿠버네티스의 주요 오브젝트

• 쿠버네티스 오브젝트 : 쿠버네티스 API 서버로 생성하는 영속성을 가지는 모든 실체
• 주요 명령어
  • run, create : 파드와 디플로이먼트 생성
  • get, exec : 생성된 파드 현황 조회 및 파드 내 bash 스크립트 실행(파드 접속)
  • scale, delete : 파드의 수량 증가/감소 및 오브젝트 삭제
  • create namespace : 네임스페이스 생성

3-1. NGINX 피드 실행과 배시 실행

• 파드
  • 쿠버네티스 환경에서 컨테이너 애플리케이션을 실행하는 기본 단위
  • 일반적으로 단일 컨테이너만 실행하지만 2개 이상의 컨테이너도 하나의 파드 안에서 실행 가능함
  • IT 업계에서의 파드 : 컴퓨팅, 네트워크, 스토리지를 모듈 형태로 묶어서 시스템 확장 시 사용하는 기본 단위를 의미
• k : 위에서 자동완성 설정함 (kubectl)

$ k run nginx --image nginx
### pod/nginx created

$ k run nginx01 --image nginx

$ k get pods
### NAME    READY   STATUS    RESTARTS   AGE
### nginx   1/1     Running   0          21s

$ k get pods -o wide
### NAME    READY   STATUS    RESTARTS   AGE    IP           NODE           NOMINATED NODE   READINESS GATES
### nginx   1/1     Running   0          113s   10.244.1.2   k8s-demo-m02   <none>           <none>
### nginx01   1/1     Running   0          14s     10.244.1.3   k8s-demo-m02   <none>           <none>

---

[교재]

2.8 MetalLB를 이용한 로드밸런서 타입 서비스 구축

• 노드포트 타입 서비스는 외부 클라이언트에서 접속했을 때 특정 도메인이 아닌 특정 노드가 실제로 사용하는 IP주소를 지정해서 접속한다.
• 노드의 IP는 변경될 수 있고 80, 443 등 기본 포트가 아닌 특수 포트 30000 ~ 32767 중 하나의 포트를 사용해야 하므로 실제 서비스에 적용하기는 어렵다.
• 쿠버네티스는 부하분산이 가능한 로드밸런서 타입의 서비스를 제공한다.
• EKS, AKS 등 퍼블릭 클라우드 업체가 제공하는 매니지드 쿠버네티스 서비스는 로드밸런서 타입의 서비스를 자체적으로 제공한다.
• 온프레미스 환경은 외부 업체가 제공하는 별도의 솔루션이 필요하다.
• 오픈소스 기반의 로드밸런서 서비스를 제공하는 대표적인 솔루션으로 MetalLB와 Porter가 있다.
• 현업에서 전용 로드 밸런서 장비의 성능 우위와 관리 편의성 등의 이유로 쿠버네티스 환경에서도 상용 물리 L4 스위치를 사용하는 경우가 있다.
• 소규모 또는 관리 역량이 있는 업체라면 오픈소스 솔루션을 사용할 수 있다.
• MetalLB는 쿠버네티스 자체 솔루션에 포함되지 않은 외부 솔루션이다.
• 쿠버네티스는 현재 클러스터 관리 솔루션에서 일종의 데이터센터 전체를 운영하는 베스트 프랙티스의 집합으로 발전하고 있다.
• 다양한 기능을 지원하는 외부 솔루션 조합이 필수이다.
• 쿠버네티스를 중심으로 다양한 오픈소스 생태계가 활성화되었다.
• CNCF는 벤더 중립적인 오픈소스 프로젝트를 육성하고 유지해서 오픈소스 생태계 활성화에 기여하는 비영리 단체로서 쿠버네티스 운영에 필수적인 다양한 솔루션을 지원하고 있다.
• 프로메테우스, 헬름, 하버 등이 대표적인 CNCF vmfhwprxmdlek.
• MetalLB와 Portereh CNCF 프로젝트이며, 이 책에서도 MetalLB 외 다양한 CNCF 프로젝트를 다룬다.

2.8.1 헬름을 이용한 MetalLB 설치

• 온프레미스에 사용 가능한 로드밸런서 타입의 서비스를 지원하는 MetalLB를 설치한다.
• MetalLB를 이용해 로드밸런서 타입의 서비스를 생성하고 정상적으로 부하분산이 되는지 확인한다.
• MetalLB는 오픈소스로서 무료로 사용할 수 있다.
• 온프레미스 환경에서 사용 가능한 로드밸런서로 다양한 곳에서 사용되고 있으며. 국내에서도 커뮤니티 발표 사례도 있고 블로그 등을 통해 사용버도 많이 공유되고 있다.

• MetalLB 설치에 앞서 로드밸런서 용도로 사용할 IP대역을 지정한다.
• MetalLB의 공식 홈페이지에 안내된 내용에 따라 헬름을 이용해 설치한다.
• my-values.yaml 파일을 수정하기 위해 비주얼 스튜디오 코드에서 파일을 연다.

로드밸런서란?

로드 밸런싱과 로드 밸런서

• 로드 밸런싱
  • 네트워크 또는 서버에 가해지는 부하를 분산해주는 기술을 의미한다.
• 로드 밸런서
  • 로드 밸런싱 기술을 제공하는 서비스 또는 장치
  • 클라이언트와 네트워크 트래픽이 집중되는 서버들 사이에 위치하며 VIP와 함게 구성된다.
  • 특정 서버에 부하가 집중되지 않도록 트래픽을 다양한 방법으로 분산하여 서브들의 성능을 최적인 상태로 유지할 수 있도록 한다.
• VIP란?
  • VIP란 로드 밸런싱의 대상이 되는 여러 서버를 대표하는 가상의 IP이다.
  • 클라이언트들은 서버의 IP로 직접 요청을 하는 것이 아니라 LB가 가지고 있는 VIP를 대상으로 요청한다.
    • 그리고 LB는 설정된 부하 분산 방법에 따라 각 서버로 요청을 분산한다.

로드 밸런서의 기본 기능

상태 확인

• 로드 밸런서는 서버들에 대한 주기적인 상태 확인을 통해 서버들의 장애 여부를 판단할 수 있다.
  • 이로 인해, 서버에 이상이 생기면 정상적으로 동작하는 서버로 트래픽을 보내주는 Fail-Over가 가능하며, 또한 TCP/UDP 분석이 가능하기 때문에 방화벽의 역할도 수행할 수 있다.
• 종류
  • L3 체크: ICMP를 이용해 서버의 IP주소가 통신 가능한 상태인지 확인한다.
  • L4 체크: TCP의 3-way handshaking을 통해 각 서버의 포트 상태를 확인한다.
  • L7 체크: 애플리케이션 계층에서 체크하는 방법으로 실제 웹 페이지에 통신을 시도해 이상유무를 파악한다.

Tunneling

• 터널링
  • 인터넷 상에서 눈에 보이지 않는 통로를 만들어 통신할 수 있게 하는 개념이다.
  • 데이터를 캡슐화해서 연결된 상호 간에만 캡슐화된 패킷을 구별해 캡슐화를 해제할 수 있다.
• 로드 밸런서의 VIP 주소로 향하는 요구 패킷이 로드 밸런싱 서버로 전달되면 로드 밸런싱 서버에서 피킷의 목적지 주소와 포트를 검사하여 가상 서버 정책과 일치할 경우, 스케줄링에 따라 실제 작업 서버로 전달하게 된다.
  • 이때 패킷을 일반적인 스트림 방식으로 전달하는 것이 아닌 캡슐 형식으로 감싸서 전달하게 된다.
  • 이렇게 전달되면 작업 서버에서는 감싸진 패킷을 다시 풀고 요청을 처리한다.

NAT

• NAT
  • IP 주소를 변환해 주는 기능이다.
  • 내부 네트워크에서 사용하던 사설 IP주소를 로드 밸런서 외부의 공인 IP주소로 변경해주며, 반대 과정도 가능하다.
• 이렇게 하면 부족한 공인 IP주소를 효율적으로 사용할 수 있지만, 로드 밸런싱 관점에서는 여러 개의 호스트가 하나의 공인 IP주소(VIP)를 통해 접속하는 것이 주 목적이다.

SNAT

• 내부에서 외부로 트래픽이 나가는 경우, 내부 사설 IP 주소를 외부 공인 IP 주소로 변환하는 방식이다.
• 집에서 사용하는 공유기가 대표적인 예시이다.

DNAT

• 외부에서 내부로 트래픽이 들어오는 경우, 외부 공인 IP 주소를 내부의 사설 IP 주소로 변환하는 방식이다.
• 흔히 집에서 사용하는 인터넷 공유기를 통해 외부에 있는 웹 서버로 접근하고자 하는 경우, 해당 요청 패킷은 반드시 해당 공유기를 거치게 되어 있다. 출발지의 사설망 IP주소가 그대로 외부 인터넷에 나가게 될 경우 수신 측은 알 수 없는 사설망의 IP 주소이므로 최종적으로 패킷을 어디로 보내줘야 할지 알 수 없게 된다.

1. 패킷 헤더에 출발지와 목적지의 주소를 기록한다. 이때, 출발지는 자신의 사설망 IP 주소를 기록한다.
2. 기본 게이트웨이 (공유기 등)에서는 외부로 나가는 패킷을 인식하게 되면, 출발지의 IP 주소를 게이트웨이 자신의 공인 IP주소로 변경한다. 이때, 별도의 NAT테이블을 보관한다.
3. 웹 서버에서 수신한 데이터를 처리한 후, 응답하여 보내는 패킷에 출발지와 목적지의 IP 주소를 아래와 같이 기록하여 보낸다. 이 때 목적지의 IP 주소는 호스트의 기본 게이트웨이 공인 IP 주소가 된다.
4. 호스트의 기본 게이트웨이에서 웹 서버가 보낸 패킷을 받으면, 기록해두었던 NAT 테이블을 참조하여 최종 목적지인 호스트의 사설 IP 주소로 변경하여 해당 호스트로 패킷을 전달한다.

• 단, 사설 네트워크에 한 대의 호스트가 아닌 여러 대의 호스트가 같은 목적지와 통신하고자 할 때, 되돌아오는 패킷의 최종 목적지가 어디가 되어야 하는지 모르는 혼선이 생길 수 있다. 이를 해결하기 위해서는 별도의 추가 포트를 설정하여 해킷을 구분하는 PAT방식을 사용하게 된다.
• 아울러, NAT 과정에서는 패킷에 변화가 생기기 때문에 IP나 TCP/UDP의 체크섬도 다시 계산되어 재기록해야하며 이에 필연적으로 네트워크의 성능에 영향을 미치게된다.

DSR

• 서버에서 클라이언트로 되돌아가는 경우, 목적지를 클라이언트로 설정한 다음 네트워크 장비나 로드 밸런서를 거치지 않고 바로 클라이언트로 찾아가는 방식이다.
• 이 경우, 로드 밸런서의 부하를 줄여줄 수 있는 장점이 있다.

로드 밸런서의 종류와 로드 밸런싱의 방법

• 로드 밸런서는 OSI 7계층을 기준으로 어떻게 부하를 분산하는지에 따라 종류가 나뉜다.
• 2계층을 기준으로 부하를 분산한다면 L2, 3 계층을 기준으로 분산한다면 L3인 방식이다.
• 상위 계층으로 갈수록 섬세한 부하 분산이 가능하지만, 가격과 성능에 드는 비용이 증가한다.
• 부하 분산에는 L4 로드 밸런서와 L7 로드 밸런서가 가장 많이 활용된다.
  • 그 이유는 L4부터 포트 정보를 바탕으로 분산하는 것이 가능하기 때문이다.
    • 한 대의 서버에 각각 다른 포트 번호를 부여하여 다수의 서버 프로그램을 운영하는 경우라면 최소 L4이상을 사용해야 한다.

L4 로드 밸런서

• L4 로드 밸런서는 L4 계층에서 동작하며, 네트워크 계층이나 트랜스포트 계층의 정보를 바탕으로 부하를 분산한다.
  • 즉, IP 주소나 포트 번호, MAC 주소, 전송 프로토콜 등에 따라 트래픽을 나누고 분산 처리하는 것이 가능하다.
  • 이러한 이유로 L4 로드 밸런서를 CLB 혹은 SLB라고 부르기도 한다.
• 로드 밸런싱 방법
• 라운드 로빈
  • 요청이 들어오는 대로 서버마다 균등하게 요청을 분배한다.
  • 단순히 순서에 따라 세션을 할당하므로 경우에 따라 경로 별로 같은 처리량이 보장되지 않는다.
• 가중치 및 비율 할당 방식
  • 라운드 로빈 방식으로 분배하지만, 서버의 가중치에 따라 요청을 더 분배하기도, 덜 분배하기도 한다.
  • 서버 가중치는 사용자가 지정할 수 있고, 동적으로 조정되기도 한다. 특정 서버의 성능이 월등히 뛰어나다면 해당 서버ㅇ게 높은 가중치를 부여한다.
• 최소 연결
  • 가장 적은 세션을 가진 서버로 트래픽을 보내는 방식이다.
  • 가장 많이 사용되는 방식이다.
• 가장 빠른 응답 시간
  • 가장 빠른 응답 시간을 보내는 서버로 트래픽을 보내 주는 방식이다.
  • 각 서버들의 가용 가능한 리소스와 성능, 그리고 처리 중인 데이터 등이 다를 경우 적합한 방식이다.
• 해시 기반 스케줄링
  • 사용자의 IP를 해싱한 후 그 결과에 따라 서버로 요청을 분배하기 때문에 특정 클라이언트는 특정 서버로만 할당하는 방식이다.
• 대역폭 기반
  • 서버들과의 대역폭을 고려하여 트래픽을 분산하는 방식이다.
    참고링크
• https://velog.io/@corone_hi/%EB%A1%9C%EB%93%9C-%EB%B0%B8%EB%9F%B0%EC%84%9C-Load-Balancer

---

[서브노트]

07.03 클러스터 외부에서 내부의 파드 연결

• NodePort 서비스

• 노드의 인터페이스(NIC) 중 하나의 포트 사용

• kube-proxy와 세 가지 모드
  : https://arisu1000.tistory.com/27839

• 부하분산(load balancing)

• NodePort 서비스의 한계

• well-known 포트 사용 불가
• 서비스 안정성 및 부하분산 문제
• 노드의 IP가 변경되면 외부 접속용 IP 주소도 함께 변경해주어야 함

Ch. 08 MetalLB를 이용한 로드밸런서 타입 서비스 구축

• NodePort 타입 서비스: 노드의 실제 IP 주소로 접근
  LoadBalancer 타입 서비스: 로드 밸런서의 IP 주소로 접근

• MetalLB

• https://metallb.universe.tf/

• LB 용도로 사용할 IP 대역을 미리 지정할 필요가 있음

• MetalLB 0.13 부터 ConfigMap 설정은 deprecated
  ⇒ 0.13부터는 MetalLB만의 CR, CRD로 설정

  • https://metallb.universe.tf/configuration/_advanced_l2_configuration/
  • https://metallb.universe.tf/apis/

Ch. 09 Traefik을 이용한 쿠버네티스 인그레스 구축

• Ingress 란?

• 스스로 찾아보세요.

• 쿠버네티스 인그레스 주요 기능
  : https://kubernetes.io/docs/concepts/services-networking/ingress/

• URL 및 경로별 백엔드 서비스 분리
• SSL/TLS 인증서 연동
• 애플리케이션 관리 효율을 위해 외부 접속에 관한 상세 규칙을 별도 인그레스 리소스로 분리