Talos Linux를 통한 간편한 Production Level K8S 환경 구축하기 - 2 -

이번 편에서는 Talos Linux 설치 후 추가적으로 해줘야하거나 해주면 좋은 설정들 등에 관하여 알아볼 것이다.

 

1. Pod Security 해결법

https://www.talos.dev/v1.7/kubernetes-guides/configuration/pod-security/

Pod Security

Talos Linux의 Pod Security 관련해서 자세한 내용은 위의 내용을 참고하면 된다.

간단하게 특정 namespace에서 pod security를 해제하고 싶다 아래 명령어를 입력하면 된다.

kubectl label ns <Namespace 이름> pod-security.kubernetes.io/enforce=privileged

여전히 Pod Security관련 Warning은 뜨겠지만 문제없이 정상 동작하는 것을 확인할 수 있다.

 

2. Metrics Server 활성화 시 발생하는 TLS 오류 해결법

Metrics Server를 사용하기 위해 rotate-server-certificates 옵션을 준 경우, 각 노드의 대시보드에서 계속하여 certificate/tls 관련 오류가 나타나는 것을 볼 수 있다.

이는 간단하게 아래 명령어 한 줄로 해결이 가능하다.

kubectl get csr -o name | xargs kubectl certificate approve

 

 

3. Nvidia Driver 활성화 방법

https://www.talos.dev/v1.7/talos-guides/configuration/nvidia-gpu-proprietary/

NVIDIA GPU (Proprietary drivers)

 

앞선 글에서 간단히 언급한 내용을 따라 Image Factory에서 Nvidia 드라이버가 추가된 Talos Linux 이미지를 생성하고, 이를 설치하였다면 반드시 아래 과정을 통해 Nvidia driver container를 활성화해야만 해당 노드가 Ready 상태로 돌입할 것이다.

 

우선, 아래 스크린샷과 같이 get extensions 명령어와 read /proc/driver/nvidia/version 명령어를 사용하여 해당 노드에 nvidia 드라이버 및 container toolkit이 설치되었는지, 또 어떤 버전의 드라이버가 설치되었는지 등의 여부를 확인할 수 있다.

 

Nvidia driver는 Proprietary drivers를 선택했다고 할 때 관리자 컴퓨터에 다음과 같은 파일들을 생성하여 저장하도록 하자.

(주석은 파일 이름을 지정하는 것이니 주석을 제외하고 파일로 넣어주면 된다.)

# nvidia_patch.yaml

machine:
  kernel:
    modules:
      - name: nvidia
      - name: nvidia_uvm
      - name: nvidia_drm
      - name: nvidia_modeset
  sysctls:
    net.core.bpf_jit_harden: 1

# nvidia_runtime_patch.yaml

- op: add
  path: /machine/files
  value:
    - content: |
        [plugins]
          [plugins."io.containerd.grpc.v1.cri"]
            [plugins."io.containerd.grpc.v1.cri".containerd]
              default_runtime_name = "nvidia"        
      path: /etc/cri/conf.d/20-customization.part
      op: create

# nvidia_runtime_class.yaml

---
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: nvidia
handler: nvidia

 

그 다음, 다음 명령어를 사용하여 각 패치들을 적용하고 K8S에 Nvidia runtime을 생성하여주도록 하자.

# Nvidia 모듈 활성화
# 이 명령어는 Reboot없이 적용되며, 적용된 이후 해당 노드는 바로 Ready상태로 돌입할 것이다.
talosctl patch mc --patch @nvidia_patch.yaml -n <적용할 노드 IP> -e <control node IP> --talosconfig=<본인 talosconfig경로>

# Nvidia Runtime을 기본으로 지정
# 이 명령어는 Reboot을 수반한다.
talosctl patch mc --patch @nvidia_runtime_patch.yaml -n <적용할 노드 IP> -e <control node IP> --talosconfig=<본인 talosconfig경로>

# Nvidia Runtime Class추가
kubectl apply -f nvidia_runtime_class.yaml

 

추가로, 각 노드들에 올라갈 Pod에서 Nvidia GPU를 사용하기 위해서는 GPU-Operator가 올라가야만 한다.

kubectl create namespace nvdp
kubectl label ns nvdp pod-security.kubernetes.io/enforce=privileged
helm install nvidia-device-plugin nvdp/nvidia-device-plugin --version=0.13.0 --namespace nvdp --set=runtimeClassName=nvidia --set gfd.enabled=true

위 명령어는 GPU operator와 NFD를 같이 올려준다.

 

 

 

성공적으로 올라갔다면 위의 사진들과 같이 Pod들이 정상적으로 올라가고 Node Labeling도 정상적으로 되며 실행한 Pod 내에서 Nvidia 명령어가 잘 동작하는 것을 볼 수 있다.

 

4. Ephemeral Storage 추가 방법

https://www.talos.dev/v1.7/kubernetes-guides/configuration/local-storage/

Local Storage

 

Talos Linux에서 추가 저장장치를 사용할 수 있는 방법은 다음과 같다.

1. OpenEBS Local Device나 Rook Ceph와 같이 파티션이 없는 디스크를 갖고 Block 스토리지 기술을 사용하는 방법

2. /var 아래에 디스크를 마운트하여 Longhorn이나 OpenEBS Local Hostpath와 같은 스토리지를 운영하는 방법

 

이 때, /var 경로를 Ephemeral Storage라고 부르고 Talos Linux는 외장 디스크를 마운트할 수 있는 위치로 Ephemeral Storage만을 허용한다.

 

개인적으로는 반드시 Longhorn을 사용하여야 한다 등의 이유가 있는 것이 아니라면 1번의 방법을 통해 스토리지를 구축하는 것을 강력 추천한다.

 

그 이유는 다음과 같다.

1. Talos Linux는 위의 Local Storage 문서에서도 볼 수 있는 것처럼 클러스터를 업그레이드 하는 경우 --preserve 옵션을 빼먹게 된다면 자동으로 Ephemeral 영역을 초기화하기 때문에 데이터를 전부 잃어버릴 수 있다.

2. 추후 설명하겠지만, Talos Linux에서 추가 저장 장치를 사용할 때 Node Config를 직접 수정, 혹은 Patch를 통해서 저장 장치 경로를 지정하고 파티션을 지정하여 해당 저장 장치를 포맷한 다음 지정된 경로에 마운트하는 방식을 취한다. 근데 이게 일회성이 아니라 노드 재실행 시마다 해당 Config를 기반으로 저장 장치를 재포맷하려고 하는데, 이 때문에 만약 USB나 추가 HDD/SSD 등이 연결되어 저장 장치의 경로가 바뀐다면 의도하지 않은 저장 장치의 포맷이 발생할 수 있고, 혹은 이미 존재하는 파티션 레이블로 인하여 OS에서 지속적인 에러가 발생할 수 있다.

3. 그리고 개인적인 경험으로는 OpenEBS Local Hostpath를 기반으로 노드를 굴리다가 아래와 같은 Ephemeral partition 오류를 겪은적이 있다. 이 때, debug container를 띄워 확인해본 바로는 정상적으로 추가 저장 장치가 마운트가 되긴 하였으나 아마 모종의 이유로 OpenEBS와 해당 저장 장치가 정상적으로 연결이 되지 않고 Talos Linux가 설치된 저장 장치의 /var 영역으로 침범하게 된 것 같다. 해당 문제는 칼같이 각 Pod가 사용할 최대 용량을 계산하고 OpenEBS Local Device로 스토리지를 구축한 이후부터는 나타나지 않았다.

 

어쨋든 만약 반드시 저장 장치를 마운트하여 사용해야 한다면 다음을 참고하여 patch 파일을 만들어주도록 하자.

# disk_patch 예시 파일.yaml

machine:
    kubelet:
        extraMounts:
            - destination: /var/mount1
              type: bind
              source: /var/mnt/mount1
              options:
                - bind
                - rshared
                - rw
            - destination: /var/mount2
              type: bind
              source: /var/mnt/mount2
              options:
                - bind
                - rshared
                - rw
    disks:
        - device: /dev/sda
          # 파티션을 설정할 때, 무조건 위에서 아래 순서로 파티션을 생성하게 된다.
          # 이 때, size 옵션 없이 mountpoint만 지정하는 파티션은 남은 용량을 전부 할당받는다.
          partitions:
            - size: 240G
              mountpoint: /var/mount1
            - mountpoint: /var/mount2

talosctl patch mc --patch @disk_patch.yaml -n <적용할 노드 IP> -e <control node IP> --talosconfig=<본인 talosconfig경로>

그 다음 위의 명령어를 실행한다면 노드를 재실행하면서 저장 장치를 포맷하고 파티션을 나눈 다음 마운트하게 된다.

이 때, Talos Linux는 기본적으로 XFS 포맷으로 파티션을 생성한다.