중요한건 꺾이지 않는 맥북

root@BD1-L-KUBESPAWNER-MASTER-001:/home# k logs -n kube-system weave-net-rxfmb weave -f DEBU: 2023/11/23 16:08:09.204629 [kube-peers] Checking peer "82:91:72:42:5a:a7" against list &{[{fe:e0:e6:ce:b5:32 bd1-l-kubespawner-master-001} {8a:bf:f3:33:54:40 c1-l-kubespawner-worker-020} {ea:fc:bf:75:e6:79 c1-l-kubespawner-worker-003} {32:a2:6b:a7:95:18 c1-l-kubespawner-worker-006} {ce:6c:75:6b:77:67 c1..

1.NVIDIA Multi-Instance GPU Nvidia, cuda 관련 toolkit, driver가 설치되어있다는 전제하에 진행했습니다! SUDO 권한으로 진행하는 것을 권장합니다. 기존에는 nvidia-smi 결과가 위와같이 MIG mode가 Disabled 인것을 볼 수 있습니다. MIG 를 적용하기 위해선, nvidia-smi -mig 1 명령어를 통해 적용할 수 있습니다. 특정 GPU 카드에만 적용하기 위해선 nvidia-smi -mig 1 -i {gpu id} 로 gpu id를 지정하여 enable이 가능합니다. 모든 gpu 카드에 적용했으나 위처럼 Enabled* 로 아래와 같은 오류가 발생한다면, 아직 사용 가능하지 않음을 의미합니다. root@OP-L-APOLLO-GPU-007:/..

상황 쿠버네티스 클러스터의 워커노드 1번 VM의 컴퓨팅 자원 Scale Up을 진행했습니다. 그 후, 몇일이 지나 워커노드가 NotReady 상태인 이슈가 발생했습니다. 당시에는 수동으로 kubelet restart를 해주어 해결했는데, 계속 주기적으로 워커노드 NotReady인 상황이 발생했습니다. kubelet 에러 메세지는 아래와 같습니다. Aug 07 10:06:02 MD2-L-KNUH-WIDE-KUBESPAWNER-WORKER-001 kubelet[40194]: E0807 10:06:02.918771 40194 conn.go:254] Error on socket receive: read tcp 127.0.0.1:45467->127.0.0.1:40854: use of closed network c..

Airflow version: 2.2.5 helm repo: apache-airflow chart version: 1.3.0 저는 쿠버네티스 환경에서 Kubernetes native하게 동작하는 Airflow 를 사용하고 있습니다. 일반적인 Airflow on Kubernetes는 사용자에게 독립적으로 Aiflow를 각각 띄워주는 방식인데, 이렇게 서비스하게 되면 컴퓨팅 자원이 기하급수적으로 늘어날것이라 예상했으며 한정적인 자원에서 Airflow를 서비스하기 위해 KubernetesExecutor 리소스를 활용하여 Kubernetes 자원을 효율적으로 사용하였습니다. KubernetesExecutor를 사용하면 다음과 같은 장점이 있습니다. (출처: https://engineering.linecorp.c..

배경 Airflow on Kubernetes 를 구축하던 상황이었습니다. helm 차트로 Airflow를 설치하던 중, PostgreSQL 생성에서 이슈가 발생했는데요. PostgreSQL 생성하는 statefulset에서는 PVC를 활용하여 저장공간을 마운트하게 되어있는데, 저는 해당 DB 를 영구적으로 보존하기 위해 postgresql 의 /bitnami/postgresql 경로를 nas 장비의 /a/b/c 라는 경로에 마운트를 해놓은 PV를 활용했습니다. 하지만, PostgreSQL Pod의 상태는 Error 였는데요. 과정 PostgreSQL Pod 의 첫번째 로그는 아래와 같았습니다. postgresql 07:19:25.61 postgresql 07:19:25.61 Welcome to the B..

KServe로 프로젝트가 이전되기 전의 KFserving standalone을 Kubernetes 상에서 구축중이었습니다. KFServing Version: 0.5.1 이슈 1 Failed to pull image "gcr.io/kfserving/kfserving-controller:v0.5.1" MacBook-Pro:kfserving-lts jaeuheo$ docker pull gcr.io/kfserving/kfserving-controller:v0.5.1 WARNING: Python 3.5-3.7 will be deprecated on August 8th, 2023. Please use Python version 3.8 and up. If you have a compatible Python inter..

주피터 컨테이너를 생성해주는 Kubespawner를 활용하여 구축한 쿠버네티스 클러스터는 마스터 노드와 워커 노드가 별도의 방화벽 정책이 필요하지 않았다. 하지만, 공공 클러스터의 보안 정책에 따라 앞으로 추가되는 워커 노드들은 방화벽(https://kubernetes.io/docs/reference/networking/ports-and-protocols/)을 열어서 클러스터를 구성해야했다. 하지만, 주피터 컨테이너를 띄웠을때 이슈가 발생했다. # k get pods -A |grep jeawoo0594-02-2mpqp9r1 jeawoo0594-02-2mpqp9r1 jupyter-jeawoo0594-2d02-2mpqp9r1 1/1 Running 0 2d1h test1-01-es02mn3h 파드가 정상적으로..

사용자가 접근하는 앱을 배포시, pod에서 curl, telnet과 같은 네트워크 통신 확인 명령어 설치를 안한 경우 k exec -it {pod} -n {namespace} -- bash # pod 에 bash 쉘로 접속한뒤 echo > /dev/tcp/{ip}/{port} 위 명령어로 해당 pod에서 외부 ip:port 로 통신 확인이 가능합니다. 해당 방법은 bash의 built-in 기능이라고 합니다. [통신 성공시] 해당 포트가 열려있는 경우 echo $? 위 명령어로 다시 확인하면 0으로 응답이 온다. 해당 포트가 열려있지 않은 경우 아래처럼 connection refused 발생한다. bash: connect: Connection refused bash: /dev/tcp/10.41.0.42/..