킹주용이다

버전이 바뀌어서인지, 퍼머링크를 잘못 설정한 탓인지

게시판에 업로드 해둔 파일의 다운로드가 정상적으로 되지 않았습니다.

암만 로그를 뚫어져라 쳐다봐도 404만 줄창 나오는데 이걸 어쩌나 생각하던 찰나에

크롬 하단에 미약하게나마 고개를 들던 친구가.. 뭔가 이상한 것을 알아차렸습니다

아니 근데 분명히 외부 개방하기 전에는 다운로드가 잘 됐는데 갑자기 이러시면 곤란한데요 ㅜ ㅜ

아무튼 이 친구를 어떻게 해보자 ! 하는 것이 목표입니다.

웹에 대한 이해가 전무한 탓에, 예전의 웹 프로그래밍 시간을 떠올려 '폴더가 추가됐으니, 폴더를 실제로 추가해주자 !'라는 단순한 생각으로 /wordpress/라는 폴더를 하나 추가 생성하여 엎어주었습니다. 네 .htaccess에 대한 이해가 전혀 없으니 하는 이야기입니다

물론 폴더를 추가해서는 작동하지 않았구요, 리다이렉트를 해야겠구나 ! 라는 생각이 든지 얼마 지나지 않아

열이 받은 저는 가능한 플러그인을 모두 동원해보았습니다

어제 사용해보았던 모든 플러그인입니다. 그 어떠한 친구도 /wordpress/가 들어간 경로를 리다이렉트시켜주지 않았고, 굉장히 오랜 시간동안 플러그인과 .htaccess를 수정해가며 싸웠습니다.

제가 간과한 사실이 하나 있는데, 이러한 문제는 대부분 공식 문서나, 기술 문서에서 해결책을 제공합니다.

네 결국은 기술 문서를 찬찬히 읽어가며 다시 한 번 머릿속으로 그림을 그려봤습니다

부디 쓸모없는 한국어 번역은 치워주시길 바랍니다

앞서 작성한 helm 차트에 아래 문구만 입력하면 '그것은 나를 위해 일했다'

allowOverrideNone: false # htaccess 파일 적용 금지를 false로

htaccessPersistenceEnabled: true # 사용자가 정의한 내용을 유지시키게

customPostInitScripts:
  enable-multisite.sh: |
    #!/bin/bash
    cat /docker-entrypoint-init.d/.htaccess > /bitnami/wordpress/.htaccess
    chmod -w bitnami/wordpress/wp-config.php
  .htaccess: |
    <IfModule mod_rewrite.c>
    RewriteEngine On					# 접근한 링크가
    RewriteCond %{REQUEST_FILENAME} !-f # 파일이나
    RewriteCond %{REQUEST_FILENAME} !-d # 디렉토리가 아닐시
    RewriteRule ^wordpress/(.*) /$1 [L] # wordpress/~/~/~를 /~/~/~ 로 Rewrite
    </IfModule>

helm config파일이야 뭐 하루 이틀 쓰는거 아니니 패스하고 .htaccess 파일은

.htaccess 파일(혹은 "분산 설정파일")을 사용하면 디렉토리별로 
설정을 변경할 수 있다. 여러 설정 지시어가 있는 파일을 특정 문서
디렉토리에 두면, 그 디렉토리와 모든 하위디렉토리에 지시어를 적용한다.

이런 일을 합니다. 그러니 저 친구가 원래 있던 위치(현재의 루트 디렉토리, wordpress 폴더 안)에서부터 읽었고, 이것때문에 이 사단이 났던 것이었습니다.

또 하나 배웠습니다. 공식 문서를 잘 읽자

이상입니다.

(작성이 끝나고 보니 빼먹은 부분이 많습니다, 추후에 글 수정 하겠습니다)

백준, 정처기 등 쿠버네티스와 관계 없는 다른 일들을 하느라 좀 늦었습니다

이번주에는 로컬에서 동작하던 워드프레스 기반 웹 사이트를 제 클러스터로 이전시켜보았습니다

아는 사람들은 아는 그곳입니다

교수님께서 속도가 너무 느리다고 말씀하시기도 했고

큰 업데이트 없이 방치되어 제가 K8s 기반으로 마이그레이션 시켜보았습니다

정도에서 벗어난 방법일 수 있습니다. 제가 했던 방식은 이러하다 ~ 정도의 글이니

틀린 점은 지적 부탁드립니다.

https://github.com/bitnami/charts/tree/main/bitnami/wordpress

helm을 사용하여 위에서 시키는 대로

helm repo add my-repo https://charts.bitnami.com/bitnami
helm install my-release my-repo/wordpress

를 수행합니다.  storageclass를 지정해주고 나면 PV가 생성될텐데, 이는 사용자마다 상이하니 생략하였습니다.

위 명령어는 초창기에만 사용하였으며, 컨텐츠를 가져오고 난 이후로부터는 values.yaml을 작성하여

helm upgrade --cleanup-on-fail  \
  --install my-release my-repo/wordpress \
  --namespace wp \
  --values /home/node10/wordpress/values.yaml

와 같이 사용해주었습니다. 아래는 참고용 values.yaml이므로 필요하신대로 작성하시면 됩니다.

참고용 values.yaml

global:
  storageClass: "nfs-client"

containerPorts:
  http: 30867

wordpressUsername: # 비밀

wordpressPassword: # 비밀

wordpressEmail: # 비밀


mariadb:
  auth:
    database: wordpress # 중요, 초기값은 bitnami-wordpress이라 db 연동 오류가 발생합니다.
    username: # 비밀    # 기존에 사용하던 db의 이름을 기입하시면 됩니다
    password: # 비밀

wordpressPlugins: none
podSecurityContext:
  enabled: true
  fsGroup: 1001


containerSecurityContext:
  enabled: true
  runAsUser: 1001
  runAsNonRoot: true
  allowPrivilegeEscalation: false

아무튼 생성된 PV로 기존에 사용하던 wp-content를 가져옵니다.

위의 helm install로 인해 생성된 wp-content 폴더를 wp-contentzzzz 등의 이름으로 변경해두고 가져온 폴더를 넣어주시면 됩니다.

wp-content를 가져오고 난 후, mysqldump로 DB를 가져옵니다.

클러스터에 생성된 mariadb에 이 ~~~~.sql 파일을 다시 덤프해줍니다.

데이터베이스 덤프가 완료되고 나면 반드시 데이터베이스를 다 열어보면서 확인해주셔야 합니다.

저는 이전 과정에서 WP를 최신버전 이미지로 사용하였고

이로 인해 플러그인의 충돌이 발생하여 굉장히 오랜 시간을 보냈습니다.

하여 이를 손으로 수정해보겠다고 PHP를 열어 하나하나 수정해보고.. 별의 별 짓 다 해보았는데

모두 부질없는 일임을 깨달았습니다

제가 해결한 방법은 PV내의 wordpress/wp-content/plugins를 plugins2 등의 다른 이름으로 변경한 것입니다.

변경하고 나면 플러그인이 비활성화된채 웹이 작동합니다.

하지만 기존의 웹은 20개 이상의 플러그인을 사용했고, 이것 없이는 도저히 정상적인 사용이 불가능하여 다른 방법을 찾아주었습니다.

우선은 뭔가 보이니 기분이 좋습니다. 하지만 이제 시작일 뿐입니다.

모든 플러그인이 사라졌으니 재설치를 하면 되겠지 ? 하는 생각이 들어 플러그인의 재설치를 시도하였으나

모든 플러그인에서 이러한 경고문구를 내뱉었습니다. 이는 분명히 무언가 단단히 잘못된 것이겠지요

하여 pod의 쉘을 열어 접속해보았습니다. mkdir도, 어떠한 수정이나 추가 삭제 등 모든 작업이 안 되는 것으로 보아 권한의 문제구나 생각이 들었습니다.

pod에게 루트 권한을 주면 간단히 풀리겠다 싶어 팟에게 루트 권한을 줄 방법을 찾았습니다.

SecretContext를 이렇게도 저렇게도 바꿔보고 .. 오만가지 방법을 다 사용해 보았습니다

그러던 중 '침해 사고 발생시 굉장히 위험할 수 있다' 라는 조언을 들어

다른 방법을 물색하다 문득 떠오른 생각

'PV 내에 있는 plugins 폴더를 777 맥이면 되지 않을까 ?'

일단 ㄱㄱ

?

이전 성공..

아무튼 결론은 PV 내의 PLUGINS 폴더에 CHOWN 777 ~~~~~ 를 적용하였더니

업데이트는 물론 파일의 열람, 다운로드, 수정까지 모두 가능했다

POD을 건드릴 게 아니라 PV를 건드려야 한다

입니다.

아 물론 이는 일시적인 해결책으로, chown 777을 남발하는 행위는 '굉장히 위험합니다'

해결 직후 권한을 수정해주는 편이 바람직합니다

이전은 성공적으로 마쳤습니다. 2~3개를 제외한(지원 중단) 플러그인들이 정상작동하고,

이전에 사용하던 게시판의 글과 유저 정보 등 모든 DB, 파일 등 모든 요소들이 정상적으로 굴러갑니다.

만약 제가 했던 방법이 자세히 알고 싶으시거나, 틀린 점이 있다면 지적해주세요

감사합니다.

스파크, 파이스파크 구성을 완료하고 GPU 분산학습을 찍먹해보고자 NVIDIA, CUDA 등 필요한 환경을 구성하던 중

클러스터에서 정상적으로 GPU를 할당하고, 사용되는 것을 확인한 후 집에 다녀왔습니다.

너무 순탄하게 흘러가더라구요.

다녀와보니

이렇게 GPU가 없는 10번 노드를 제외한 모든 노드들이 취침중이었습니다

이전에 전원 문제로 인해 서버랙 차단기가 내려가 모든 노드가 죽은 경험은 있었지만

이렇게 꺼졌다는 것은.. 제가 GPU 로드 과정에서 무언가 잘못을 했다는 얘기겠지요

처음에는 전원 문제인 것으로 판단하고 다시 켜보고..

그래도 다시 꺼져서 또 켜보고.. 혹시 절전모드가 활성화 되어있나 확인도 해보고

무슨 방법을 써도 모든 노드가 15분 정도면 꺼지고 말았습니다.

혹시나 하는 마음에 아무 노드에 모니터를 연결한 순간

이런 당황스러운 화면이 저를 맞이했습니다.

GUI가 생겼네? 왜 ? 어떻게 ? 이건 몰랐는데

제가 했던 생각은

'GUI이니 절전모드가 있을 것이고, 별개로 작동할 것이다' 였습니다

setting -> power -> black screen - never 로 설정해주고

잠시 기다렸습니다. 하지만 it didn't work for me....

아래의 명령어로 해결했습니다.

sudo systemctl status sleep.target suspend.target hibernate.target hybrid-sleep.target

위는 확인하는 명령어인데, GUI에서 black screen을 해제하고 나니 status가 변경되었습니다.

아래의 명령어로 사용 해제해줍니다.

sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

예전에 클러스터 구성 과정에서 발생했던 오류입니다.

이번엔 Jupyterhub 운용중에 hub-xxxxxxxx pod이 무한 pending에 빠졌고

로그와 이벤트를 찍어보던 와중에 해당 오류를 발견하였습니다.

kubelet과 통신하는 10250 포트가 어느샌가 닫혀있었고

전체 노드의 10250포트를 열어주어 해결했습니다.

어제는 성공한 게 아니었습니다

주피터 허브는 열렸는데 노트북이 열리지 않고  무한 pending에 빠지는 바람에..

우선 참고한 문서부터

https://z2jh.jupyter.org/en/latest/jupyterhub/installation.html

https://z2jh.jupyter.org/en/latest/jupyterhub/customization.html

https://github.com/jupyterhub/zero-to-jupyterhub-k8s/blob/main/jupyterhub/values.yaml

트러블슈팅

https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner
https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner/issues/114
https://stackoverflow.com/questions/50156124/kubernetes-nfs-persistent-volumes-permission-denied

https://docs.run.ai/admin/integration/jupyterhub/

https://discourse.jupyter.org/t/singleuser-pods-stuck-in-pending/6349/11

제가 최종 작성한 config.yaml 는 아래와 같습니다.

앞으로 계속 수정이 있을 예정입니다.

정답이 아니고, 수많은 시행착오를 거쳐 수정에 수정을 거듭하여,,

제가 했을 때 이렇게 하니 되더라 ~ 이니 참고'만' 하시고,

나머지는 위의 문서들 보고 입맛대로 작성하시는 편이 좋겠습니다

꿀팁 드리자면 한국어 레퍼런스는 8할이 k3s, 미니큐브, 퍼블릭 클라우드 등

나와는 관계 없는 환경에서 진행한 것들이기에 그냥 스택 오버플로우나 https://discourse.jupyter.org/ 보시는게 좋습니다

proxy:
  secretToken: "<#터미널에서 openssl rand -hex 32의 결과를 여기에 복붙#>"
  service:
    nodePorts:
      http: 30360 # 임의 지정
    loadBalancerIP: 192.168.0.100 # 임의 지정

ingress:
  enabled: true

cull:
  enabled: true
  timeout: 3600
  every: 300

singleuser:
  cmd: ["jupyterhub-singleuser"]
  profileList:
  - display_name: "선택할 프로필"
    description: "에 대한 설명"
    default: true

  memory:
    limit: 
    guarantee: 1G
  cpu:
    limit:
    guarantee: 0.5
  storage:
    homeMountPath: /home/{username}
    dynamic:
      storageClass: nfs-client
      storageAccessModes: [ReadWriteMany]
    capacity: 100Gi

  extraFiles:
    jupyter_notebook_config.json:
      mountPath: /etc/jupyter/jupyter_notebook_config.json
      data:
        MappingKernelManager:
          cull_idle_timeout: 1800
          cull_interval: 600
          cull_connected: false
          cull_busy: false

scheduling:
  userScheduler:
    enabled: false

hub:
  service:
    type: ClusterIP
  config:
    JupyterHub:
      admin_access: true
      admin_users:
      - cslab
      
debug:
  enabled: true

설치 과정은 위의 공식 문서와 동일하게

helm upgrade --cleanup-on-fail \
  --install jupyter jupyterhub/jupyterhub \
  --namespace jupyter \ # 미리 namespace를 만들어 두시거나, create 옵션을 넣어주시기 바랍니다
  --version=1.2.0 \ # 2.0.0은 알 수 없는 오류가 많아서 1.2.0으로 돌아왔습니다
  --values config.yaml # 위에서 작성한 config.yaml, 해당 디렉토리에서 설치 수행해야 함

helm 차트를 사용합니다.

이상입니다. 간단합니다

이러고 나서

kubectl get svc -n jupyter

로 proxy-public의 EXTERNAL IP, port를 확인하여 접속하시면 되는데

그렇게 간단할 리가 없겠죠 ?

제가 겪었던 문제들을 읊어보도록 하겠습니다.

PVC가 bound 되지 않는 문제

저는 마스터가 아닌 노드에서 NFS 서버를 열어 그곳을 저장소로 사용하였는데

PVC가 바운딩 되지 않는 문제가 발생하였습니다.

위의 helm 명령어를 실행하면 자동으로 생성되는 PVC를

kubectl delete pvc hub-db-dir -n jupyter

로 지워버리고

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  annotations:
    meta.helm.sh/release-name: jupyterhub
    meta.helm.sh/release-namespace: jhub
  labels:
    app: jupyterhub
    app.kubernetes.io/managed-by: Helm
    chart: jupyterhub-1.2.0
    component: hub
    heritage: Helm
    release: jupyterhub
  name: hub-db-dir
  namespace: jupyter
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: nfs-client
  volumeMode: Filesystem

위와 같이 pvc.yaml을 작성하여

kubectl apply -f pvc.yaml -n jupyter

PVC를 새로 만들어 주었습니다.

만약 PVC를 생성하였는데도 문제가 발생한다면

kubectl get sc -A

를 찍어보시고 storageclass가 있는지, pvc에 할당이 되어있는지 확인하시기 바랍니다.

동적 프로비저닝을 사용하였는데 이 부분도 추후에 수정하겠습니다.

외부 접속이 되지 않을 때

config.yaml의 ingress.enabled를 true로 고쳐보시기 바랍니다

허브가 열리지만 user pod이 pending에서 머무르다가 Timeout 될 경우

config.yaml의 scheduling.userScheduler:enabled 를 false로 바꿔보시기 바랍니다

위의 오류들과 트러블슈팅에  사용한 문서 이외에도 수정한 사항이 굉장히 많습니다.

시도해본 것이 너무 많아 모두 정리하지 못해 아직 부족합니다.

이후에 메모해둔 것들과 기억나는 것을 모두 종합해서 글 수정하도록 하겠습니다.

다음 시간에는 스파크와 GPU 연산을 해보겠습니다.

감사합니다

내가 해냈다

주피터 허브 여는데 약 4~5일 걸렸습니다

ㅋㅋㅋㅋㅋㅋㅋㅋ

과정은 나중에 쓸게요

나 화이팅 !@!!!!!!

우선 5일차 대신 5회차로 쓴 이유는

방학중에 이벤트가 많아서..ㅎㅎ 네 그렇게 됐습니다

전체 노드에 IP 할당, 네트워크 구성 끝

8번 노드는 SSH 설정을 잘못 건드린건지 무슨 방법을 써도 authorized_keys 적용이 안 되네요

이제 가장 큰 문제는 7번 노드의 이상입니다

분명히 HDD 교체도 해줬는데,, 뭐 어쩌자는건지

아마도 메인보드에 눈에 보이지 않는 부식이나 단선이 있는 것으로 추정되니

7번 노드는 그냥 버리고 나중에 안쓰는 메인보드를 갖다 붙여야겠네요

아무튼 네트워크 구성까지 마쳤으니 이제 control-plane에서 

kubeadm init

만 해주면 된다고 생각했는데

수십번 본 오류인데 볼 때마다 화가 잔뜩 납니다

원인을 생각해보니

1. CRI

2. 서비스 재시작

3. systemd 설정

중에 하나일텐데 무슨 방법을 써도 돌아오지 않았습니다

여기서 굉장히 많은 시간을 헤메던 와중에 공식 문서를 찬찬히 다시 읽어보았는데

근데 왜 그걸 이제 알려줌

트러블슈팅하는 방법도 다 알려주면서

왜 이건 안 알려줬냐

암튼 그래서 containerd로 넘어가기로 했습니다

# 노드 반절 정도는 swapoff를 해주지 않았길래 그냥 공통으로 작성해버림
# https://kubernetes.io/docs/setup/production-environment/container-runtimes/
# 참고했음
swapoff -a
# 컨테이너드 가져오기
wget https://github.com/containerd/containerd/releases/download/v1.6.15/containerd-1.6.15-linux-amd64.tar.gz
#압축 해제
tar Cxzvf /usr/local containerd-1.6.15-linux-amd64.tar.gz
# 데몬 리로드, 컨테이너드 사용
systemctl daemon-reload
systemctl enable --now containerd
# runc 다운로드
wget https://github.com/opencontainers/runc/releases/download/v1.1.4/runc.amd64
# runc 설치
install -m 755 runc.amd64 /usr/local/sbin/runc
# cni plugin 다운로드
wget https://github.com/containernetworking/plugins/releases/download/v1.1.1/cni-plugins-linux-amd64-v1.1.1.tgz
#압축해제
mkdir -p /opt/cni/bin
sudo xzvf /opt/cni/bin cni-plugins-linux-amd64-v1.1.1.tgz
# 도커, 도커엔진, 컨테이너드, 런씨 그냥 싹다 삭제(k8s-도커 레퍼런스에서 이렇게 하라고 했는데
# 왜 이렇게 쓴건진 이해가 잘 안됨. 다운로드 하라고 해놓고 바로 삭제 ? 흠
# 이유를 아신다면 알려주시길 바래요
sudo apt-get remove docker docker-engine docker.io containerd runc
sudo apt-get update
# 다시 설치,, 도커 공식 문서 참고함
# https://docs.docker.com/engine/install/ubuntu/
sudo apt-get install \
    ca-certificates \
    curl \
    gnupg \
    lsb-release
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt-get update
sudo chmod a+r /etc/apt/keyrings/docker.gpg
sudo apt-get update
sudo apt-get install docker-ce docker-ce-cli containerd.io docker-compose-plugin
sudo docker run hello-world
#IPv4 포워딩 및 iptables에서 브리지된 트래픽 확인
cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF
sudo modprobe overlay
sudo modprobe br_netfilter

# sysctl 파라미터 재부팅해도 유지되도록
cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-iptables  = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.ipv4.ip_forward                 = 1
EOF
# sysctl 적용
sudo sysctl --system
# 컨테이너드 disabled_plugins 그냥 삭제해버림(cri 비활성화 오류 해결)
sudo sed -i '/disabled_plugins/d' /etc/containerd/config.toml
# 컨테이너드 재시작
systemctl restart containerd
# kubeadm join 당신의 조인 코드를 넣어주세요

주석에 달아놓은 것과 같이

굳이 설치하고 다시 지우는 이유는 모르겠지만

일단 그 부분은 시키는대로 해보았습니다

그랬더니

아 물론 10회 반복해서 나온 결과입니다

한번에 뚝딱 되지는 않아요

NotReady.. 이거 분명히 한달 전에도 이 문제로 머리가 아팠는데

잠시 고민해보니 CNI 설정을 하지 않은 것이 생각났습니다

WeaveNet 말고 Calico로 설치해보았습니다

전부 Ready 상태로 전환되었습니다

control-plane이 NotReady인 이유는

컨트롤 플레인에게 작업을 할당하지 않도록 초기 설정이 되어있는 것으로 알고 있습니다

자 클러스터 구성도 마쳤고 이제 서비스 배포를 실습해보도록 하겠습니다

부족한 점이 많으니 지적 부탁드립니다,,

이상입니다 감사합니다

16대를 뜯었는데 결국 10대만 사용 가능

위처럼 부식된 메인보드가 너무 많아서 사용 가능한 부품들만 떼어냈습니다

떼어낸 부품들을 어찌어찌 호일도 감고 폐기하고

총 보드 4장에 HDD 1장, 파워 1개가 폐기되었습니다

그렇게 완성된 친구입니다

네트워크는 라우터, 24포트 스위치로 구성하였고

추후에 속도 등의 문제가 발생할 경우 보완해야 할 것으로 보입니다

전체 노드에 포트 포워딩 설정과 계정 변경도 해주고

이제 정말 실습할 일만 남았습니다

시간이 오래 걸린 이유는 HDD 스캔도 있지만

저 무거운 컴퓨터를 열몇대씩 뜯어다가 옮기고

분해하고 쓸만한 부품 떼어내 재조립하다 보니 시간이 많이 들었습니다

배드섹터 검사를 마친 녀석들을 VGA가 달려있는 노드들에 장착하고
부팅해 보았는데... DHCP 설정이 무언가 잘못되었습니다
temporary failure in name resolution, network is unreachable 등의
오류가 지속적으로 발생하고, 다른 하드디스크를 장착해도 달라지지 않았습니다.
너무 오랜만이라 이런 말도 안 되는 실수를,,

sudo vim /etc/netplan/*.yaml

netplan을 위와 같이 수정해 줍니다.
ethernets에서 enp0s31f6 등의 네트워크 어댑터의 이름은

ip a

를 통해 알 수 있습니다

IP를 할당받은 결과입니다.

resolv.conf에 nameserver 8.8.8.8를 추가해도 소용이 없고
방화벽을 해제해도 지속적으로 오류가 발생하는 분들은
혹시 하드디스크를 바꿔 끼우지는 않았나 고민해 보시고
네트워크 어댑터도 한 번 확인해보시기 바랍니다
ㅜ ㅜ

복구, 설치가 완료된 녀석들로 구성하여 5개는 부활 성공했습니다
나머지는 내일 하고 클러스터 구성 미리 해야지,,
화이팅,,

약 5년 정도 방치돼있던 클러스터를 살려보기로 마음먹었습니다
일단 무턱대고 서버실에 왔는데 아무래도 괜히 건드린 것 같은 느낌이 드네요
그냥 교수님께서 폐처리하라고 하실 때 할걸 그랬나 봅니다

서버랙에 붙어있는 노드가 총 16개
여기에 한 3~4개 덧붙여서 20개 정도로 K8S 클러스터를 구성해볼 예정입니다
서비스는 아직 생각해보지 않았지만 일단 환경부터 구축을 해보도록 하겠습니다
먼저 HDD를 다 뜯어서 배드섹터 검사부터 시작할 예정입니다

개중에 이런 녀석들도 있었습니다
장기를 모조리 적출당하고, CPU 캡까지 씌워진 순살 메인보드
파워 없이 랜선만 덩그러니 꽂혀있었어요

기막힌 배선정리 한 번 구경하고 가세요

제가 간과한 사실이 하나 있는데
HDD라 검사속도가 무지 느립니다
개당 13시간 정도 걸리는데.. 6개 남았으니까.. 78시간만 더 하면 되지 않을까 싶네요

적출한 장기들을 전시해둔 모습
하나씩 테스트하려고 다른 부품들은 뜯지 않았습니다.
뜯기 시작하면 둘 데가 없어서 우선 HDD부터 시작합니다.
GPU를 기준선으로 왼쪽은 우분투, 도커, k8s 등등 필요한 것들을 모두 올려둔 하드
오른쪽은 아직 배드섹터 검사도 안 한 것들
맨 오른쪽은 검사는 끝났고, 다시 os부터 차근차근 올려야 할 녀석들입니다.

설치할 때 하나하나 작성하기 귀찮으니
명령어 스크립트 하나 만들어서 쓰면 좋습니다.

sudo vim kube-inst.sh

로 sh파일 하나 만들어서
아래 스크립트를 모조리 집어넣고

sudo sh kube-inst.sh

를 입력하면 알아서 설치, 테스트까지 해줍니다.

apt install docker.io
docker ps
sleep 2s

swapoff -a
sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab
sleep 2s

sudo apt-get update && sudo apt-get install -y apt-transport-https curl
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
cat <<EOF | sudo tee /etc/apt/sources.list.d/kubernetes.list
deb https://apt.kubernetes.io/ kubernetes-xenial main
EOF
sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl
sudo apt-mark hold kubelet kubeadm kubectl
sleep2s
kubeadm version

좌측에 쌓인 것들은 GPU 박힌 친구들, 우측은 GPU 없는 친구들
그 앞은 장기를 모조리 누군가에게 적출당한 친구들이라
우선은 왼쪽의 GPU 달린 친구들부터 살려보도록 하겠습니다.

오늘의 일기는 여기서 끝