Cloud/Kubernetes 썸네일형 리스트형 Rook-ceph는 뭐하는 놈일까? 보호되어 있는 글입니다. Ubuntu 18.04 Read-only file system이 뜨는 멍청한 행동을 했을 때 K8S 설치할 때 SWAP 꺼야하는데 그 때 주석처리 잘못해서 (내가 멍청해서) 볼륨이 다 잠겼다... 잠기면 이렇게 된다. root@C1-9:~# cd -bash: cannot create temp file for here-document: Read-only file system -bash: cannot create temp file for here-document: Read-only file system 처음에는 손발이 줄줄 눈물이 덜덜이였는데 한 번 해봐서 그런지 이제 괜찮다. 먼저 마운트 옵션을 보자 root@C1-9:~# cat /proc/mounts | grep /dev udev /dev devtmpfs rw,nosuid,relatime,size=8099844k,nr_inodes=2024961.. 까먹을까봐 쓰는 k8s tomcat stress 테스트 하기 FROM tomcat:latest USER root RUN apt-get update -y RUN apt-get install -y stress //Dockerfile tomcat 부하테스트 하는데 만들기 귀찮다 docker build . -t docker push 이후에 exec로 접근하여 stress 주면 된다. Kubernetes Worker 해제 설치하다보면 Worker를 해제해야하는 때가 온다. 물론 그냥 이렇게 해도 된다 kubeadm reset 하지만 문제점이 많다. 워커는 이미 해제되어 있는데 마스터에 포드는 그대로 떠있다던가... 지우는게 아주 골치아파지니까 해제 이후 리셋해주도록 한다. root@C1-3:~# kubectl get nodes NAME STATUS ROLES AGE VERSION c1-3 Ready master 138m v1.15.3 c1-6 Ready 99m v1.15.3 c1-9 Ready 99m v1.15.3 노드 정보를 확인한 이후 지워줄 노드를 drain 해준다 root@C1-3:~# kubectl drain c1-9 root@C1-3:~# kubectl get nodes NAME STATUS ROLES AGE .. Kubernetes 설치 중 metal-lb controller 생성 문제 - metal-lb controller 제대로 안뜰 때 -failed to set bridge addr: "cni0" already has an IP address- - controller가 계속 생성중일때가 있다. 그럴 땐 ifconfig로 cni0, flannel.1 을 확인해본다. describe 해보면 cni0이 IP를 이미 가지고 있다고 나오는데 이는 재설치 시 이전 환경과 부딪혀서 그런 것 같다. kubeadm reset systemctl stop kubelet systemctl stop docker rm -rf /var/lib/cni rm -rf /var/lib/kubelet/* rm -rf /etc/cni ifconfig cni0 down ifconfig flannel.1 down ifco.. 쿠버네티스의 리소스 리소스 용도 노드 컨테이너가 배치되는 서버 네임스페이스 쿠버네티스 클러스터 안의 가상 클러스터 파드 컨테이너의 집합 중 가장 작은 단위, 컨테이너의 실행 방법 정의 레플리카세트 같은 스펙을 갖는 파드를 여러 개 생성, 관리 디플로이먼트 레플리카 세트의 리비전 관리 서비스 파드의 집합에 접근하기 위한 경로 정의 인그레스 서비스를 쿠버네티스 크러스터 외부로 노출 컨피그맵 설정 정보를 정의하고 파드에 전달 퍼시스턴트볼륨 파드가 사용할 스토리지의 크기 및 종류를 정의 퍼시스턴트볼륨클레임 퍼시스턴트 볼륨을 동적으로 확보 스토리지클래스 퍼시스턴트 볼륨이 확보하는 스토리지의 종류를 정의 스테이트풀세트 같은 스펙으로 모두 동일한 파드를 여러 개 생성하고 관리 잡 상주 실행을 목적으로 하지 않는 파드를 여러 개 생성하고.. 쿠버네티스 구조 살펴보기 2013년도에 도커가 발표되면서 컨테이너 기술은 예~전에 사용하던 사용자 격리 수준의 LXC 방식, 배포에 더욱 신경을 쓴 Docker Container 방식, 오케스트레이션(컨테이너 관리)을 위한 Docker Swarm, Kubernetes로 진화하고 있다. 컨테이너 오케스트레이션이란 컨테이너를 관리하는 방법이라고 정리할 수 있다. 물론 도커로도 컨테이너를 관리할 수 있다. 하지만 컨테이너가 만 개가 되면? 다른 서버에서 사용한 컨테이너와 통신하고 싶다면? 인프라의 규모가 커지면서 이러한 고민은 필연적인 숙명이 되고 결과적으로 나타난 것이 컨테이너 오케스트레이션이다. (갓) 구글에서 발표한 오케스트레이션 기술인 Kubernetes는 업계 표준이나 다름없어졌으며 많은 곳에서 사용되고 있다. 공부하다 보니.. 이전 1 ··· 5 6 7 8 9 다음
