실전 과제 — 클러스터 구성

결론부터

• 차트를 파일로만 뽑으라는 과제는 helm template으로 끝난다. CRD를 빼는 옵션은 차트마다 달라 helm show values에서 찾는다.
• CNI를 고르라는 과제는 요구 기능으로 가른다. NetworkPolicy를 적용해야 하면 Flannel은 답이 아니다.
• 노드 준비 과제는 “지금 적용”과 “재부팅 뒤에도 유지”를 둘 다 해야 끝난다.
• CRD의 필드 설명은 kubectl explain으로 읽고, 출력을 그대로 파일에 저장한다.

과제는 연습용으로 만든 시나리오이고 이름과 값은 예시다. 과제마다 조건 → 풀이 → 확인 → 함정 순서로 읽고, 원리는 링크한 개념 페이지에서 확인한다. 호스트 접속과 네임스페이스 확인은 문제마다 반복하는 3단계를 따른다.

Helm 차트를 CRD 없이 파일로 렌더하기

과제

• External Secrets Operator의 공식 차트 저장소 https://charts.external-secrets.io를 eso라는 이름으로 등록한다.
• 차트 버전 2.10.0을 네임스페이스 external-secrets 기준으로 렌더해 ~/eso.yaml에 저장한다.
• CRD는 클러스터에 이미 설치되어 있으므로 결과에 넣지 않는다.

풀이

1. 저장소를 등록하고 버전이 있는지 본다.

   helm repo add eso https://charts.external-secrets.io
   helm repo update
   helm search repo eso/external-secrets --versions | head -5

2. CRD를 끄는 값을 찾는다. 키 이름은 차트마다 다르다.

   helm show values eso/external-secrets --version 2.10.0 | grep -n -i crd
   # 57:installCRDs: true

3. 버전·네임스페이스·값을 지정해 렌더하고 파일로 보낸다.

   helm template external-secrets eso/external-secrets \
     --version 2.10.0 \
     --namespace external-secrets \
     --set installCRDs=false > ~/eso.yaml

4. 결과를 확인한다.

   grep -c 'kind: CustomResourceDefinition' ~/eso.yaml     # 0
   grep -m1 'helm.sh/chart' ~/eso.yaml                     # external-secrets-2.10.0
   grep -m1 'namespace:' ~/eso.yaml                        # external-secrets

함정

• helm template은 클러스터에 아무것도 설치하지 않는다. 과제가 파일 저장까지면 helm install을 하지 않는다.
• --version을 빼면 최신 버전이, --namespace를 빼면 default가 들어간다. 둘 다 에러 없이 틀린 결과가 나온다.
• CRD를 빼는 방법은 차트 구조에 따라 --skip-crds이거나 차트의 값이다. 한쪽만 외우지 않는다.

두 방법의 차이는 차트의 CRD를 넣고 빼기에서 본다.

NetworkPolicy를 지원하는 CNI 골라 설치하기

과제

• 클러스터에 CNI가 없어 노드가 NotReady다. 지문이 제시한 Flannel과 Calico 중 하나를 골라 설치한다.
• 설치한 CNI는 NetworkPolicy를 자체적으로 적용할 수 있어야 한다.
• 두 후보의 매니페스트 주소는 지문에 주어진다.

풀이

1. 요구 기능으로 후보를 가른다. Flannel은 NetworkPolicy를 적용하지 않으므로 Calico를 고른다.

2. 클러스터의 Pod 대역을 확인한다. CNI 쪽 설정과 맞아야 한다.

   kubectl get configmap kubeadm-config -n kube-system \
     -o jsonpath='{.data.ClusterConfiguration}' | grep podSubnet

3. 오퍼레이터 매니페스트를 create로 넣는다. <주소>는 지문의 값이다.

   kubectl create -f <tigera-operator 매니페스트 주소>
   kubectl get pods -n tigera-operator

4. Installation 리소스를 넣는다. 오퍼레이터는 이 리소스를 보고 Calico를 설치한다. Pod 대역을 2단계 값으로 맞춘 뒤 적용한다. 전체 순서는 CNI 설치의 예와 같다.

5. Calico Pod과 노드 상태를 확인한다.

   kubectl get pods -n calico-system
   kubectl get nodes                              # Ready

함정

• 오퍼레이터만 넣고 끝내면 노드는 계속 NotReady다. 오퍼레이터는 설치를 맡는 컨트롤러일 뿐이다.
• 큰 CRD가 든 매니페스트는 kubectl apply에서 애너테이션 크기 제한에 걸릴 수 있다. create를 쓴다.
• 두 CNI를 모두 설치하지 않는다. /etc/cni/net.d/에 설정이 둘이면 사전순으로 앞선 것이 쓰인다.

CNI별 NetworkPolicy 지원 여부는 CNI — 누가 네트워크를 만드는가의 표에 있다.

cri-dockerd 설치와 커널 파라미터 설정으로 노드 준비하기

과제

• 노드에 Docker Engine이 설치되어 있다. 홈 디렉터리의 cri-dockerd.deb 패키지를 설치한다.
• cri-dockerd 서비스를 지금 시작하고, 부팅 때도 자동으로 시작되게 한다.
• 다음 커널 파라미터를 1로 설정하고 재부팅 뒤에도 유지되게 한다. net.ipv4.ip_forward, net.bridge.bridge-nf-call-iptables, net.bridge.bridge-nf-call-ip6tables

풀이

1. 패키지를 설치한다. dpkg -i는 저장소를 거치지 않고 로컬 .deb 파일을 설치한다.

   sudo dpkg -i ~/cri-dockerd.deb

2. 서비스를 켜고 부팅 등록까지 한다. enable은 부팅 등록, --now는 지금 시작이다.

   sudo systemctl enable --now cri-docker.service
   systemctl is-enabled cri-docker.service        # enabled
   systemctl is-active cri-docker.service         # active

3. 브리지 관련 키가 생기도록 커널 모듈을 올린다.

   sudo modprobe br_netfilter

4. 파라미터를 파일에 쓰고 적용한다. 키 이름은 지문에서 그대로 옮긴다.

   cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
   net.ipv4.ip_forward                 = 1
   net.bridge.bridge-nf-call-iptables  = 1
   net.bridge.bridge-nf-call-ip6tables = 1
   EOF
   sudo sysctl --system

5. 현재 값을 확인한다.

   sysctl net.ipv4.ip_forward net.bridge.bridge-nf-call-iptables net.bridge.bridge-nf-call-ip6tables

함정

• 패키지 이름은 cri-dockerd지만 systemd 유닛 이름은 cri-docker다. 이름이 기억나지 않으면 systemctl list-unit-files | grep cri로 찾는다.
• systemctl start만 하면 재부팅 뒤 꺼지고, sysctl -w만 하면 재부팅 뒤 값이 사라진다.
• br_netfilter 모듈이 올라와 있지 않으면 net.bridge.* 키 자체가 없어 그 값은 적용되지 않는다.

cri-dockerd가 필요한 이유는 Docker Engine을 쓸 때 — cri-dockerd, 파라미터의 뜻은 노드 준비에서 본다.

설치된 CRD 목록과 필드 문서를 파일로 저장하기

과제

• 클러스터에 설치된 Gateway API의 CRD 목록을 ~/gateway-crds.txt에 저장한다.
• HTTPRoute의 spec.hostnames 필드 문서를 ~/httproute-hostnames.txt에 저장한다.

Gateway API CRD가 설치된 클러스터를 전제로 한다. 다른 오퍼레이터의 CRD로 바꿔도 방법은 같다.

풀이

1. CRD 이름에 들어 있는 API 그룹으로 걸러 저장한다. CRD 이름은 <복수형>.<그룹> 형식이다.

   kubectl get crd | grep gateway.networking.k8s.io > ~/gateway-crds.txt

2. 필드 문서를 explain으로 뽑아 저장한다.

   kubectl explain httproute.spec.hostnames > ~/httproute-hostnames.txt

3. 두 파일을 열어 내용이 들어갔는지 본다.

   cat ~/gateway-crds.txt
   head ~/httproute-hostnames.txt
   # GROUP:      gateway.networking.k8s.io
   # KIND:       HTTPRoute
   # VERSION:    v1
   # FIELD: hostnames <[]string>

함정

• CRD는 클러스터 범위 리소스다. -n은 필요 없다.
• 지문이 요구하는 것이 필드의 문서인지 특정 오브젝트의 값인지 구분한다. 문서는 kubectl explain, 값은 kubectl get <리소스> <이름> -o jsonpath=...다.
• explain의 필드 경로는 대소문자를 구분한다. 경로가 기억나지 않으면 kubectl explain httproute.spec으로 한 단계씩 내려간다.

CRD를 조회하는 명령은 설치된 CRD 살펴보기에 모아 두었다.