개요

T-LoxiLB vs MetalLB를 하면서, 내 조약한 Vagrant가 너무 못나보였다.
세팅을 새로 어떻게 할지 고민하는 것은 이제 그만!
클러스터 관련 세팅을 조금 더 자유롭게 하기 위해서는 이런 세팅에 조금 더 친숙해져야만 한다.
그래서 조금 더 유연하게 세팅하고 관리 효율성을 증가시키고자 새로 세팅을 진행한다.

현황

일단 내 기본 vagrant 세팅은 이런 식이다.

거의 모든 세팅이 vagrantfile에 들어있다.
nfs 서버를 같이 세팅해서 매번 새로 nfs 서버가 켜지는 방식이다.

가장 아쉬운 건 이것이다.
워커를 내 맘대로 여러 개 두고 싶은데 vagrantfile을 커스텀할 만큼 ruby 문법에 익숙치 않아서 그냥 전부 일일히 적어줬다;
근데 LoxiLB의 예제 vagrantfile을 보니 훨씬 세팅을 간단하게 관리하면서 가시적인 문법을 사용할 수 있었다.
그래서 그것에 맞게 바꾸고자 한다.

세팅 파일 분리

이런 식으로 세팅 파일을 분리해서, 전체적으로 변경을 시키고 싶은 변수들을 외부로 둘 수 있다.
이렇게 관리하는 건 파일의 분리를 야기하기 때문에 그렇게 좋은 방식이 아닐 수도 있다.
그러나 자주 변경될 여지가 있는 값들, 그리고 공통적으로 적용되는 값들을 관리하는데 도움을 줄 것이다.

이 파일은 이렇게 YAML.load_file을 통해 불러오면 되며, 이후부터는 json 객체처럼 다루면 된다.
내 생각에는 여기에 기본 하드웨어 관련 설정들을 넣으면 된다.
클러스터 관련 설정에 대해서도 항상 고정적인 것이 있다면 여기에 넣어주면 좋을 것이다.

컨트롤 플레인 HA 염두

컨트롤 플레인을 여러 개 두는 시나리오를 생각해볼 만하다.
아직은 하지 않았지만 장차 실습해볼 방향이라 처음부터 이를 고려하는 세팅을 할 것이다.

이렇게 ruby 식 반복을 돌면서 master를 설정할 수 있도록 한다.
그러나, 아직은 바로 하지는 않을 거고, HA 구성을 할 수 있는 준비만 해두는 것이다.

vagrant 작업

뜻하지 않게 루비 문법에 대해서도 조금 더 알아가는 시간을 가지고 있다..

vagrant로 호스트 스크립트 실행

vagrant up을 할 때 특정 트리거를 발동시킬 수 있더라.
그런데 여러 개가 한꺼번에 될 때, 매번 이 스크립트가 실행돼서 내 선택지는 아니라 생각했다.

박스 이미지 수정

박스 이미지도 갈아끼우자.
가장 많이 쓰이는 것은 bento에서 만들어주는 박스이다.^[1]

버전에서 문제가 있다는데..어때 해보니까 버전을 명시 안 해야 설치가 된다..?
버전을 명시 안 하니 최신 버전이 아닌 202404.26.0이 설치됐다.

vagrant 최종

스크립트는 이런 식으로 썼다.
루비에서도 변수를 만들어서 사용할 수 있구나..
많은 것들을 또 알아간다.

쿠버네티스 설정

kubeadm 설정

apiVersion: kubeadm.k8s.io/v1beta4
bootstrapTokens:
- groups:
  - system:bootstrappers:kubeadm:default-node-token
  token: abcdef.0123456789abcdef
  ttl: 24h0m0s
  usages:
  - signing
  - authentication
kind: InitConfiguration
localAPIEndpoint:
  advertiseAddress: 1.2.3.4
  bindPort: 6443
nodeRegistration:
  criSocket: unix:///var/run/containerd/containerd.sock
  imagePullPolicy: IfNotPresent
  imagePullSerial: true
  name: node
  taints: null
timeouts:
  controlPlaneComponentHealthCheck: 4m0s
  discovery: 5m0s
  etcdAPICall: 2m0s
  kubeletHealthCheck: 4m0s
  kubernetesAPICall: 1m0s
  tlsBootstrap: 5m0s
  upgradeManifests: 5m0s
---
apiServer: {}
apiVersion: kubeadm.k8s.io/v1beta4
caCertificateValidityPeriod: 87600h0m0s
certificateValidityPeriod: 8760h0m0s
certificatesDir: /etc/kubernetes/pki
clusterName: kubernetes
controllerManager: {}
dns: {}
encryptionAlgorithm: RSA-2048
etcd:
  local:
    dataDir: /var/lib/etcd
imageRepository: registry.k8s.io
kind: ClusterConfiguration
kubernetesVersion: 1.32.0
networking:
  dnsDomain: cluster.local
  serviceSubnet: 10.96.0.0/12
proxy: {}
scheduler: {}

kubeadm config print init-defaults로 config 파일을 꺼내서 커스텀이 가능하다.
여기에서 kubelet과 kube-proxy 설정도 해줄 수 있다.
추가적으로 입력해주면 되는 건데, 내 kube-proxy가 ipvs로 동작하게 하고 싶다면 미리 해주는 게 좋은가?
init 과정의 설정은 join할 때도 전부 적용된다.
근데 kube proxy는 데몬셋으로 배포되니, 데몬셋 설정을 바꾸는 방식으로도 가능하지 않을까?
흠. 나는 일단 해당 설정들은 넣지 않도록 하겠다.
이후에 다른 실습을 할 때 이걸 활용하면 딱 좋을 것 같다.

kubelet ip 세팅 편하게 하기

나는 이 코드를 보고 감동 받고 말아버렸읍니다..
왜 이렇게 할 생각은 못 했을까.. 어떻게든 하면 방법이 있었을 텐데 굳이 더 고민 안 한 지난 날의 나를 다시금 꾸짖자..

간단히 풀어서 보자면, 원하는 네트워크 인터페이스에 대해서 ip 주소를 추출해내는 방법이다.
jq에서 if문을 쓸 수 있는 것을 처음 알았다..
ip에서 json을 꺼내려면 다른 인자보다 --json을 먼저 넣어야 한다.

컨테이너 런타임 고민

컨테이너 런타임은 뭐가 좋을까 알아보려고 하는데.. 이런 걸 찾았다.^[2]
근데 이런 게 논문이야..?
내가 그냥 혼자 공부하는 것들도 논문거리가 되는 건가..?
아무튼 disk io에서 차이가 있다는 것이 요지다.
사실 컨테이너야 그냥 가상화만 하는 건데, 그 기반에서 다른 성능이 차이가 나기도 쉽지는 않을 것이라 생각한다.

컨테이너 런타임을 설정하다가 발생한 문제 중 하나.
containerd가 계속 샌드박스 이미지로 pause 3.8을 쓴다는 문구가 거슬려서 3.10으로 설정하려고 했다.^[3]
그런데 이 설정이 제대로 먹지 않아서 소켓이 생성 안 된 이슈.

kubectl config 경로

export KUBECONFIG="${KUBECONFIG}:~/project/clutser-kubernetes/.kube/config"

작업은 다 끝났다.
kubectl에서 사용할 kubeconfig 경로를 여러 개 지정할 수 있다.^[4]
내 config 파일을 직접 홈 디렉토리에 옮기는 것도 방법이나, 나는 이렇게 설정하는 게 더 좋다고 생각한다.
매번 수동으로 옮기는 것부터가 하나의 불필요한 작업이다.
또한 이 세팅법을 알아둔다면 다음부터는 그냥 이 변수의 값만 확인해서 클러스터 통신을 어떤 파일로 하고 있는지 알고 있으니까 좋다고 생각한다.

자, 일차적인 리모델링 성공이다.

생각 못한 이슈가 하나 있는데, 무효화된 config 설정이 경로에 있으니 자동완성을 하려고 할 때 해당 경로에 대한 get 요청을 날리려다 시간이 오바된다..

nfs 대안 - smb

NFS로 CSI를 생각이었는데, 잠시 고민하고 포기했다.
일단 내 목표는 내 나스를 외부 스토리지로 삼는 것이다.
그런데 여기에서 nfs를 쓰면 전송 간 암호화가 이뤄지지 않기에 패킷 탈취의 위험성이 존재한다.
그럼 나스에서 편하게 제공하는 프로토콜을 이용하는 것이 좋은데, 그렇다면 webdav나 smb가 있겠다.
그러면서 csi 드라이버를 제공해주는 것은 smb에 하나가 있다.^[5]
smb의 경우엔 전송 중 암호화를 지원하기에 시도할 가치가 있다고 판단했다.^[6]

helm repo add csi-driver-smb https://raw.githubusercontent.com/kubernetes-csi/csi-driver-smb/master/charts
helm install csi-driver-smb csi-driver-smb/csi-driver-smb --namespace kube-system --version v1.16.0

헬름 values 파일을 봤는데, 딱히 설정할 건 없어 보여서 그냥 바로 진행했다.

apiVersion: v1
data:
  password: MTIzNHF3ZXI=
  username: a3ViZS11c2Vy
kind: Secret
metadata:
  name: smb_creds
---
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: smb
provisioner: smb.csi.k8s.io
parameters:
  source: //smb-server.default.svc.cluster.local/share
  # if csi.storage.k8s.io/provisioner-secret is provided, will create a sub directory
  # with PV name under source
  csi.storage.k8s.io/provisioner-secret-name: smbcreds
  csi.storage.k8s.io/provisioner-secret-namespace: default
  csi.storage.k8s.io/node-stage-secret-name: smbcreds
  csi.storage.k8s.io/node-stage-secret-namespace: default
reclaimPolicy: Delete  # available values: Delete, Retain
volumeBindingMode: Immediate
allowVolumeExpansion: true
mountOptions:
  - dir_mode=0777
  - file_mode=0777
  - uid=1001
  - gid=1001

다음에는 스토리지 클래스를 만들어주면 된다.

그럼 이제부터 에러를 해결하는 과정이다!

일단 나스쪽에서 5000번 PID를 가진 kube-user를 만든다.

sudo mount -v -t cifs //172.30.1.60/smb tmp -o vers=3.0,username=kube-user,password=1234qwer,dir_mode=0777,file_mode=0777,cache=strict,actimeo=30

내 로컬에서는 cifs-utils를 설치해준 이후 마운팅이 너무너무 잘되는 부분입니다요..

파일 암호화를 강제하도록 세팅했는데, 그래서 이렇게 나온다는 게 말이 되나..?
아 ㅋㅋ 디렉토리를 tmp로 해서 실수...

아무튼 매우 잘 된다.

vm에서도 접근이 원활한데, 컨테이너에서는 안 되고 있다.
smb를 통한 접근이 나스 측 로그에 남지를 않아서, 확인이 어렵다;;

이유는 찾긴 했다.
그냥 시크릿에 인코딩할 때 줄바꿈이 들어감..
역시 시크릿을 직접 만들 때는 그냥 명령형으로 만드는 게 짜세다..

한가지 생각해본 사항이 있다.
집밖에 있을 때와 집 안에 있을 때 주소를 어떻게 할 것인가.
집에 있을 때와 밖에 있을 때를 확인하고, 어드미션을 적용하는 방향으로 구현하면 좋을 것 같다.
근데, 더 생각이 든 사항 중 하나는 집 밖에서 스토리지 사용은 자제하는 게 좋을 것 같다.
포트를 하나 더 포트포워딩시켜줘야 하는데, 공격 표면을 넓히는 것이 썩 마음에 내키지는 않는다.
또 이렇게 생각이 든 이유 중 하나는, 방금 smb 설정이 생각 이상으로 너무 쉬웠다는 것이다.
마운팅을 할 때 유저와 비번을 요구할 수 있는데 이 정보에 대한 암호화가 걱정되기도 하고, 그게 괜찮다고 하더라도 문제는 남아있다.
시크릿에 저장되는 유저 정보가 가장 마음에 걸린다.
저장 간 암호화를 구현하지도 않은 상태라 함부로 정보를 담아두는 것은 꺼림칙하다.

관련 문서

참고