service mesh 구성 중에 nas에 grafana 데이터를 배포하는 과정에 에러가 발생하여 기록합니다.

PV, PVC yaml 값

kind: PersistentVolume
apiVersion: v1
metadata:
  name: grafana-pv
spec:
  capacity:
    storage: 10Gi
  nfs:
    server: [nas address]
    path: [nas path]
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: grafana-pvc
  namespace: istio-system
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 10Gi
  volumeName: grafana-pv

아래 URL로 들어가서 grafana repo를 찾습니다.

https://artifacthub.io/

친절히 repo 추가 방법을 알려줍니다.

helm repo add grafana https://grafana.github.io/helm-charts
helm repo update

helm search repo grafana # 필요한 차트를 찾기
helm pull grafana/grafana # 사용할 차트를 PULL

다운로드한 차트의 압축을 풀어줍니다.

생성한 PVC에 데이터를 집어넣어야 하기 때문에 values.yaml에서 416번째 줄에서 persistence 를 활성화 합니다.

이미 생성된 PVC를 사용하기 때문에 existingClaim에 pvc를 추가합니다.

persistence:
  type: pvc
  enabled: true
  # storageClassName: default
  ## (Optional) Use this to bind the claim to an existing PersistentVolume (PV) by name.
  volumeName: ""
  accessModes:
    - ReadWriteOnce
  size: 10Gi
  # annotations: {}
  finalizers:
    - kubernetes.io/pvc-protection
  # selectorLabels: {}
  ## Sub-directory of the PV to mount. Can be templated.
  # subPath: ""
  ## Name of an existing PVC. Can be templated.
  existingClaim: grafana-pvc
  ## Extra labels to apply to a PVC.
  extraPvcLabels: {}
  disableWarning: false

필요에 따라 values.yaml을 수정한 후에 배포합니다.

정상적으로 POD가 배포되지 않습니다.

로그를 확인했을 때, chown과 init-chown-data라는 init contaier에 대한 문제가 발생한 것을 확인 할 수 있습니다.

values.yaml에서 init container에 관련 된 내용을 찾아보면 아래와 같습니다.

# values.yaml의 452번째 줄
initChownData:
  ## If false, data ownership will not be reset at startup
  ## This allows the grafana-server to be run with an arbitrary user
  ##
  enabled: true

  ## initChownData container image
  ##
  image:
    # -- The Docker registry
    registry: docker.io
    repository: library/busybox
    tag: "1.31.1"
    sha: ""
    pullPolicy: IfNotPresent

  ## initChownData resource requests and limits
  ## Ref: http://kubernetes.io/docs/user-guide/compute-resources/
  ##
  resources: {}
  #  limits:
  #    cpu: 100m
  #    memory: 128Mi
  #  requests:
  #    cpu: 100m
  #    memory: 128Mi
  securityContext:
    readOnlyRootFilesystem: false
    runAsNonRoot: false
    runAsUser: 0
    seccompProfile:
      type: RuntimeDefault
    capabilities:
      add:
        - CHOWN
      drop:
        - ALL

mount 한 NAS의 스냅숏으로 인하여 chown이 정상적으로 작동하지 못하여 init container가 종료되어 서비스가 정상적으로 올라올수 없는 것을 확인 할 수 있습니다.
이는 CSP 마다 상이하기 때문에, 이와 같은 동일한 케이스가 발생하지 않고 정상적으로 프로비저닝이 될 수 있습니다.

따라서 init contaier를 비활성화 하고 수동으로 NAS의 디렉토리 영역을 472:472로 변경합시다.

initChownData:
  ## If false, data ownership will not be reset at startup
  ## This allows the grafana-server to be run with an arbitrary user
  ##
  enabled: false

삭제 후 재설치를 진행합니다.

이후 ingress 구성 후 웹브라우저로 접근합니다.

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 상태 조회

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

NKS로 구성된 쿠버네티스 시스템에서 워커노드를 재부팅 이후로 시스템이 무너지는 현상이 발생했는데, 조회를 해보니 calico, CSI, kube-proxy 같은 코어 이미지들이 워커노드에 존재하지 않아 컨테이너가 올라오지 못해 발생하였습니다.

이는 k8s에서 노드의 디스크 용량이 부족하게 될 경우에 가비지 컬렉션이 동작하여 특정 기간 동안 사용되지 않은 이미지들을 삭제하여 용량을 확보를 하는데, 해당 코어 이미지가 삭제가 되고 난 이후로 레지스트리에서 자동으로 받아오지 못하여 워커노드가 무너지는 현상이었습니다.

https://kubernetes.io/ko/docs/concepts/architecture/garbage-collection/

이는 특히 폐쇄망 환경으로 이루어진 쿠버네티스 클러스터에서 발생하기 쉬운데, 이는 Habor 같은 사설 레지스트리에 이

미지 파일을 별도 관리하거나 Proxy 등을 통해 해결하여야 합니다.

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

또는 워커노드에 nerdctl 등을 통해 ImagePullBackOff가 발생하는 이미지를 직접적으로 받아 온 후에 컨테이너를 살리는 방법이 있습니다.

이미지를 받아오는 방법은 두가지 정도로 제안될 수 있는데, 공식 레포지토리에서 받아오거나, NHN 레지스트리에서 받아오는 방법입니다.

1. 공식 레포지토리

# 공식 레포지토리
kubernetesui/dashboard
k8s.gcr.io/pause
k8s.gcr.io/kube-proxy
kubernetesui/dashboard
kubernetesui/metrics-scraper
quay.io/coreos/flannel
quay.io/coreos/flannel-cni
calico-kube-controllers
calico-typha
calico-cni
calico-node
coredns/coredns
k8s.gcr.io/metrics-server-amd64
....

# Kube-proxy 이미지를 복구하고 싶은 경우
nerdctl pull k8s.gcr.io/kube-proxy/[$Failed Image]
nerdctl tag k8s.gcr.io/kube-proxy/[$Failed Image]
nerdctl rmi k8s.gcr.io/kube-proxy/[$Failed Image]

2. NHN 레지스트리

nerdctl pull harbor-kr1.cloud.toastoven.net/container_service/[$Failed Image] # 이미지를 가져옴
nerdctl tag harbor-kr1.cloud.toastoven.net/container_service/[$Failed Image] # 가져온 이미지명을 Yaml에서 요구하는 이미지로 변경
nerdctl rmi harbor-kr1.cloud.toastoven.net/container_service/[$Failed Image] # 변경전 이미지 삭제

이미지 장애 상태 구현하기 위해 coredns의 yaml을 수정하여 불능 상태로 만들었습니다.

복구 과정은 아래와 같습니다.

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

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: 사용자마다 다릅니다.

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