1. 설치

$ curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3
$ chmod +x get_helm.sh
$ ./get_helm.sh

# 심볼릭
$ ln -s /usr/local/bin/helm /usr/bin/helm

# 혹은 /etc/profile에 path 추가
$ echo "export PATH=\$PATH:/usr/local/bin" >> /etc/profile
$ source /etc/profile

명령어 자동 완성 추가하기

# 현재 사용중인 세션
$ source <(helm completion bash)

# 새로운 세션 연결시
$ helm completion bash > /etc/bash_completion.d/helm

설치를 완료했으니, 필요한 패키지를 설치하기 위한 저장소가 필요합니다.

https://artifacthub.io/

페이지에서 설치가 필요한 패키지를 검색합시다.

저는 예시로 nginx 를 사용할거고, bitnami 저장소를 이용하겠습니다.

박스 모양에 커서를 갖다대면 repo URL이 나오는데 복사합시다.

해당 URL로 repo 추가를 합시다.

# Repo 추가
$ helm repo add bitnami https://charts.bitnami.com/bitnami

# Repo 패키지 리스트 업데이트
# yum 혹은 apt 같은 패키지 관리자의 update 기능이라고 생각하시면 편합니다.
$ helm repo update

저장소 추가 후에 검색해보면 잘 나옵니다.

설치 방법은 이전의 사이트에서 install 를 클릭하면 확인 할 수 있고, 하단의 See all을 누르면 배포 패키지의 버전 리스트를 확인 할 수 있습니다.

해당 페이지에서 안내하는 install 방법은 아래와 같습니다.

helm install은 helm install [NAME] [CHART] [flags] 순이며, 차트를 참조하거나 디렉토리를 직접적으로 참조 할 수도 있습니다.

$ helm install my-nginx bitnami/nginx --version 18.1.7

# ex 예시
# 차트 참조 : helm install $(my-nginx) nginx/nginx
# 패키지 차트 경로 : helm install $(my-nginx) ./nginx-1.2.3.tgz
# 압축을 푼 차트 디렉토리 경로 : helm install $(my-nginx) ./nginx
# 절대 URL : helm install $(my-nginx) https://example.com/charts/nginx-1.2.3.tgz
# 차트 참조 및 저장소 URL : helm install --repo https://example.com/charts/ mynginx nginx

해당 명령어로 생성 후에 조회해보면 정상적으로 생성되는 것을 확인 할 수 있습니다.

근데 우리는 values 값에 대한 수정이 필요하기 때문에 이걸로 설치 할 수 없습니다, 따라서 helm pull을 통해 패키지를 직접적으로 가져와야 합니다.

$ mkdir nginx
$ cd nginx
$ helm pull bitnami/nginx
$ tar -xvf nginx-*.tgz
$ cd nginx

압축을 푼 디렉토리로 이동하면 여러개의 yaml과 디렉토리가 존재하는 걸 볼 수 있습니다.

여기서 패키지를 설치할 때 차트의 기본 구조는 아래와 같습니다.

values.yaml을 통해 해당 인스턴스를 값을 정의하고, templates가 정의된 값을 통해 인스턴스를 구성합니다.

nginx-chart/
├── Chart.yaml
├── values.yaml
├── crds/
│   └── mycustomresource.yaml # 필요시 작성하는 커스텀 yaml
└── templates/
    ├── deployment.yaml
    ├── svc.yaml
    └── ingress.yaml
    └── ....

pull하여 가져온 chart에서 업로더가 제공한 README 등을 통해 양식에 맞게 values.yaml을 수정하고,

helm install을 통해 설치하면 되겠습니다.

$ helm install my-nginx . # 현재 디렉토리를 참조하여 my-nginx 패키지 설치

2. 여담

명령어 

helm list : helm chart 조회

helm uninstall $(charts) [...]  [flags] : charts 삭제

helm status $(charts) : charts 상태 조회

타르코프를 하시는 분은 SPT(singleplayer Tarkov Project)를 잘 알고 있을 것입니다.

PVP 기반의 FPS를 싱글플레이 게임으로 변경하여 즐기는 모드입니다.

이 SPT라는 모드에 fika 모드를 추가하게 되면 멀티플레이를 지원하는데 그러면 PVE로 친구들과 같이 즐길 수 있습니다.

이전의 sitcoop라는 모드도 있었지만 매우 불안정하고, 기존의 SPT 모드를 별도로 포팅해야 할 수 있어서 매우 불편했습니다. (지금은 사실상 사장된 모드)

필자는 개인 서버 겸, NAS 겸 24/7 굴려먹는 맥미니가 있는데 이 SPT AKI는 exe,dll 을 사용을 하다보니 리눅스 기반에서는 어떻게 올릴 수 있을까 고민하다 도커로 사용하기로 했고, SPT를 Mac에 도커로 구성하고 FIKA를 설치하였습니다.

이런 컨테이너 방식이 아닌 a to z 하게 구성을 하면, 와인부터 시작하여 구성을 전부 다시하여야 하고.. 버전업이 되면 관리하기가 너무 어려워 저는 도커로 진행하는 것을 추천드립니다.

궁금하신 분은 하기 링크 읽어보시면 될 것 같습니다.

https://dev.sp-tarkov.com/MadByte/Linux-Guide/src/branch/main/README.md

1. SIT 설치

참고한 GIT은 아래의 링크입니다.

https://github.com/umbraprior/SPT.Docker

git clone https://github.com/umbraprior/SPT.Docker.git
cd SPT.Docker

Dockerfile을 열어보면 SPT_BRANCH라고 버전을 지정하는 부분이 있는데, 여기서 사용할 버전을 기입하면 됩니다.

작성일 기준으로 최신 버전은 3.9.1 이지만

https://hub.sp-tarkov.com/

필요한 모드를 설치할 때 버전이 높으면 호환이 안되는 부분이 있으니 반드시 확인하고 버전을 선택하세요.

docker build --no-cache  --label fikaa -t ${저장할 이미지 이름 (예: fika)}

빌드가 완료 된 후에 image를 조회 해보시면 빌드된 이미지를 확인 할 수 있습니다.

docker run 으로 해당 이미지를 실행합시다.

docker run --pull=never -v /${SPT 설치 경로}/SPT.Docker/server:/opt/server -p 6869:6969 -p 6870:6970 -p 6871:6971 -p 6872:6972 -it --name ${컨테이너명} ${이미지명}

# 저는 기존 서버가 존재하므로 6869:6969로 포트포워딩이 지정되어있습니다.
# 별도로 다른 포트 (예: 8080포트를 서버 접근 포트로 지정하고 싶으면 8080:6969) 로 지정해주세요.

run 실행 후에 mount 된 가상 경로에 리얼 데이터를 copy하는데, 해당 작업 이후로 컨테이너가 종료됩니다.

이후 server 디렉토리에 접근하게 되면 각 데이터들이 있는데 delete_me 를 삭제 한 후에 docker run 이 아닌, docker start로 종료된 컨테이너를 다시 시작해주세요.

이후 정상적으로 실행이 되었는지 확인하기 위해 docker logs -f ${컨테이너명}로 확인합시다.

이후 fika 모드를 넣으시면 됩니다.

https://github.com/project-fika/Fika-Server

모드를 다운로드 받아서 ftp로 직접 넣거나, wget을 통해서 서버에서 직접 받아 압축을 풀어 넣거나 해당 부분은 본인의 자유 입니다.

/${설치경로}/SPT.Docker/server/user/mods/fika-server

파일 업로드 후에 docker rm -f ${컨테이너명} 으로 완전히 컨테이너를 삭제하고, 다시 재기동 합시다.

(delete_me는 시작할때마다 새로이 생성되므로, 삭제 후에 docker start로 다시 기동해주세요.)

그럼 이제 카파컨 따러갑시다.

해당 게시글은 기록과 자료 공유를 위해 작성합니다.

NHN Cloud의 프라이빗 레지트스트리(NCR)의 PULL, PUSH 의 가이드는 공식 문서에도 잘 적혀있으니
참고 하도록 합시다.

https://docs.nhncloud.com/ko/Container/NCR/ko/user-guide/

프라이빗 레지스트리를 이용하기에 앞서 NCR 생성 후, 접근을 위하여

계정 -> API 보안 설정 탭에 들어가서 Access Key ID 생성을 합니다.

생성된 레지스트리를 클릭하여 주소 확인을 합시다.

레지스트리에 로그인합니다.

Username과 Password는 이전에 생성하였던 API 보안 설정에서 생성한 User Access Key 입니다.

$ docker login {사용자 레지스트리 주소}

테스트용 이미지를 받아줍니다. (본인이 필요한 이미지가 있을 경우, 해당 이미지로 pull 하여 수정 후 commit 합시다.)

[root@ysh-kube-mgmt test3]# docker pull nginx:stable

작동 확인을 위해 간단히 실행만 하였습니다.

[root@ysh-kube-mgmt test3]# docker run -itd -p 80:80 --name=web nginx:stable
9ee7f649badf5818ab6380be6ead2b4825b9a8e2d610fd4f691027464a6a4550

[root@ysh-kube-mgmt test3]# docker ps -a
CONTAINER ID   IMAGE          COMMAND                  CREATED         STATUS         PORTS                               NAMES
9ee7f649badf   nginx:stable   "/docker-entrypoint.…"   3 seconds ago   Up 2 seconds   0.0.0.0:80->80/tcp, :::80->80/tcp   web


[root@ysh-kube-mgmt test3]# curl localhost
<!DOCTYPE html>
<html>
<head>
<title>Welcome to nginx!</title>
<style>
html { color-scheme: light dark; }
body { width: 35em; margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif; }
</style>
</head>
<body>
<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href="http://nginx.org/">nginx.org</a>.<br/>
Commercial support is available at
<a href="http://nginx.com/">nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>
</body>
</html>

이후 업로드 할 이미지를 tag 명령어를 사용해 레지스트리 주소/이미지 이름:태그로 변경 후, 업로드 합시다.

# 이미지 태그 변경
$ docker tag $이미지 이름:$태그 $사용자 레지스트리 주소/$이미지 이름:$태그

# 업로드
$ docker push $이미지 이름:$태그 $사용자 레지스트리 주소/$이미지 이름:$태그

NCR 에서 확인하였을 때, 정상적으로 업로드 된 것을 확인 할 수 있습니다.

해당 프라이빗 레지스트리에 업로드 된 이미지를 쿠버네티스에 활용하기 위해선 시크릿을 생성하여 자격증명을 해야합니다.

자세한 내용은 쿠버네티스 공식 문서에도 기술되어 있습니다.

https://kubernetes.io/ko/docs/tasks/configure-pod-container/pull-image-private-registry/

문서를 인용하였을 때, 도커 로그인 시 자격증명을 저장하는 config.json의 위치를 기재하도록 명시되어있는데, 이는 이전에 API로 NCR에 로그인 하였을 때, 경로를 표기하여 줬을 것입니다.

kubectl create secret generic regcred \
    --from-file=.dockerconfigjson=<path/to/.docker/config.json> \
    --type=kubernetes.io/dockerconfigjson

저는 루트를 활용하여 사용하였기 때문에 루트 홈 디렉토리의 .docker에 작성된 것을 확인 할 수 있습니다.

[root@ysh-kube-mgmt test3]# docker login {저장소명}-kr1-registry.container.nhncloud.com/{저장소명}
Username: 
Password:
WARNING! Your password will be stored unencrypted in /root/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store

Login Succeeded

해당 경로의 파일을 출력해보면, 자격 증명을 저장하는 설정 값이 들어가있습니다.

이 컨픽값이 저장된 json으로 secret을 생성하여 줍니다.

[root@ysh-kube-mgmt .docker]# kubectl create secret generic regcred --from-file=.dockerconfigjson=/root/.docker/config.json  --type=kubernetes.io/dockerconfigjson
secret/regcred created

secret가 잘 생성되었는지 확인합시다.

[root@ysh-kube-mgmt ~]# kubectl get secrets regcred
NAME      TYPE                             DATA   AGE
regcred   kubernetes.io/dockerconfigjson   1      3h45m

아까 업로드한 이미지를 테스트하기 위한 간단한 YAML 예시입니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  labels:
    app: test
spec:
  replicas: 1
  selector:
    matchLabels:
      app: test
  template:
    metadata:
      labels:
        app: test
    spec:
      containers:
      - name: web
        image: {저장소명}-kr1-registry.container.nhncloud.com/{저장소명}/web:1.0
        ports:
        - containerPort: 80
      imagePullSecrets:
      - name: regcred

작성된 YAML로 프로비저닝 합시다.

[root@ysh-kube-mgmt test3]# kubectl apply -f web.yaml
deployment.apps/web created

이후 POD의 이미지를 조회하였을 때, 정상적으로 프라이빗 레지스트리에서 가져오는 것을 확인 할 수 있습니다.

kubectl 치트 시트 | Kubernetes

레드헷 계열

yum install bash-completion -y​

source /usr/share/bash-completion/bash_completion
source <(kubectl completion bash)
echo "source <(kubectl completion bash)" >> ~/.bashrc

데비안 계열

apt-get install bash-completion -y

source /usr/share/bash-completion/bash_completion
source <(kubectl completion bash)
echo "source <(kubectl completion bash)" >> ~/.bashrc

kubectl 입력 후, tab 입력시 확인 가능

오픈소스 시스템이자 컨테이너 배포를 관리하고 오케스트레이션 하기 위한 도구

오케스트레이션 : 쿠버네티스로 컨테이너를 다룰 때 사용되는 다양한 관리 기능에 대한 자동화를 뜻한다.

일반적인 시스템의 경우에는 사람이 실시간으로 모니터링을 하다 장애가 발생되면 트러블슈팅을 하는것이 통상적인 프로세스지만, 쿠버네티스로 오케스트레이션을 진행하여 자동화를 구성할 경우에는 컨테이너를 모니터링하고 장애 발생 시, 자동으로 컨테이너를 교체하여 장애에 대한 빠르고 자동화된 대응을 할 수 있다.

이로써 쿠버네티스를 사용하여 보다 쉽게 자동 배포, 스케일링, 로드밸런싱, 매니지먼트를 할 수 있다.

쿠버네티스의 설정으로는

배포를 정의하는 구성파일, 배포할 컨테이너, 인스턴스 수, 스케일 확장 유무, 교체 유무 등을 설정 할 수 있으며,

이 설정을 기반으로 인스턴스에 전달하게 된다.

쿠버네티스의 구성 파일은 특정 CSP에 종속되지 않고 다양한 클라우드를 선택하여 사용 할 수 있다.

추가적으로 A의 클라우드 시스템에는 기본적인 구성이 B 클라우드에서는 포함되지 않는다면 해당 누락 구성 파일을 단순히 추가만 해준다면 사용 할 수 있는 장점이 있다.

이러한 특정 시스템에 종속된 플랫폼이 아닌 표준화된 기술로 인해, 보다 쉽고 빠르게 구성 할 수 있다는 장점으로 쿠버네티스는 많은 사람들에게 각광을 받고 있다.

해당 게시글은 기록과 자료 공유를 위해 작성합니다.

회원가입 및 기타 세팅은 생략합니다.

콘솔에 로그인을 하고 난 후, 서비스 선택 탭에 들어가 컨테이너 서비스의 NKS, NCR, NCS 활성화를 하여 주세요.

서비스 신청(활성화)이 완료가 되고 나면, 좌측 탭의 컨테이너에서 NKS를 선택합니다.

각 요청에 따른 필수 탭을 기입 한 후 생성을 진행하면 되는데, k8s, 파드 네트워크의 경우 기존 VPC와 되도록이면 다른 대역대로 설정하는 것이 네트워크 구성의 가독성을 높일 수 있습니다.

이후 가용성 영역과 인스턴스 타입, 필요한 노드 수를 선택합니다.

추가 네트워크 주소가 필요 할 경우, 하단의 서브넷을 추가하여 네트워크를 추가합니다.

오토스케일러의 설정 유 무, 워커 노드 프로비저닝 시 사용자 스크립트가 필요할 경우 해당 스크립트를 추가하여 VM 생성을 진행합시다.

마지막으로 NHN Cloud의 경우 클러스터의 마스터 노드 권한이 없기 때문에, 클러스터를 제어하기 위한 관리 콘솔이 별도로 필요합니다.

따라서 NKS 생성이 진행되는 동안 일반 인스턴스 타입을 하나 더 생성 하도록 하겠습니다.

인스턴스 생성이 완료가 되면, 인스턴스에 접속을 한 후 kubectl 설치를 진행합니다. 

저는 yum으로 진행하였습니다.

보다 상세한 내용은 공식 문서를 참고 하시길 바랍니다.

https://kubernetes.io/docs/tasks/tools/install-kubectl-linux/

sudo -i

cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-\$basearch
enabled=1
gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
yum install -y kubectl

kubectl 설치가 완료되면, 연동이 필요하기 때문에 NKS 콘솔에서 config 파일을 다운로드하여 기입합니다.

작성된 예시는 아래 코드와 같습니다.

cd ~
mkdir .kube
touch .kube/config

cat <<EOF > .kube/config
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: 사용자마다 다릅니다.
    server: https://사용자마다 다릅니다.
  name: "toast-ysh-kube-test"
contexts:
- context:
    cluster: "toast-ysh-kube-test"
    user: admin
  name: default
current-context: default
kind: Config
preferences: {}
users:
- name: admin
  user:
    client-certificate-data: 사용자마다 다릅니다.
    client-key-data: 사용자마다 다릅니다.

이렇게 기본적인 클러스터 및 관리 서버 구성이 완료가 되었습니다.