Kubenetes with VMware(On-Premise)
Kubernetes and vSphere
Container vs Virtual Machine ?
vSphere로 가상화 환경이 구성되어 있는 상태에서 개별 워크로드를 관리하고 있는데 왜 굳이 컨테이너 환경을 구성하려고 하는가?에 대한 현재 환경에서의 고민
자원 관리
- 현행 수준
- 모니터링 후 자원 조정량 파악
- 자원 조정이 필요할 경우 서비스 다운 후 자원 변경
- 자원 변경 후 정상 동작 확인
- 장점 : 크게 어려운 점은 없고, 쉽고, 손으로 하나하나 만져야되서 일이 많은 것 같지만 베이스 자원이 널널해서 최적화하지 않으면 최초 설치 후 만질 일 자체가 별로 없음
- 단점 : 결국 손으로 자원 설정을 해야하고, 최초 설치 후 만질 일을 만들지 않게 하기 위하여 자원을 여유롭게(방만하게?) 잡게 됨(CRUD용 와스 싱글서버 메모리 16GB 실화?). 선언적으로 자원을 관리하고 싶은 욕망을 충족시켜주지 못함. 뭔가 기술 부채가 쌓이고 있는 것 같은 기분이 듦.
- 해결 :
- 자원에 대한 Declarative한 관리를 위하여 terraform과 같은 프로비저닝 툴 도입
- 기술 갈증은 관리자의 마음이므로 마음을 비움
- 현행 수준
배포
- 현행 :
- 로컬 개발 후 운영 중인 시스템에 카피
- 젠킨스가 깃랩으로 운영 서버에 CI/CD 관리
- 장점 : 개발자가 학습을 할 필요가 없다.
- 단점 : 각 시점별 런타임 환경 관리가 안된다.
- 해결 :
- 운영서버의 개별 조작을 막고 매 배포마다 런타임이 포함된 풀 패키지를 관리.
- 현행 :
관리
- 현행 : 켜져 있는 서버에 배포
- 장점 : 개발자가 서버 자체를 건드릴 일이 없다.
- 단점 : 배포의 단점의 연장선인데 동일 클러스터의 복제 서버 구성이 달라질 수 있다. 예를 들어 1, 2, 3, 4서버가 있는데 마음이 급해서 1, 2, 3 서버만 설정을 바꾸고 4번 서버는 메롱메롱한다거나, 4번 서버에 개발자가 마음이 급해서 IDE를 설치한다거나... 톰캣(WAS) 버전이 다른 경우도 있고 운영 중 정말 다양한 케이스를 만날 수 있음
- 해결 :
- 매 배포에 런타임을 포함한 패키지를 배포함
결국 런타임이 포함된 각 버전을 관리/배포하며 운영할 수 있는 도구가 필요한 셈인데 시장에서는 Kubernetes가 대세인 것 같아서 검토해보고자 한다.
Kubernetes on vSphere
개별 VM으로 Kubernetes 클러스터를 구성해도 되지만 VCenter에 붙어있는 자원(ESXi에서 제공하는 컴퓨팅 리소스와 네트워크, 스토리지 시스템이 제공하는 스토리지)을 네이티브하게 땡겨 쓸 수 있으면 좋을 것 같다.
- vSphere에서는 CPI(Cloud Provider Interface), CSI(Container Storage Interface)를 제공한다.
- Cloud Provider Interface(CPI) : 클라우드 프로바이더 인터페이스
- Container Storage Interface(CSI) : 컨테이너 스토리지 인터페이스. 컨테이너용 블륨 제공을 해주는 API. 쿠버네티스 클러스터에 플러그인 설치하고 vsphere에 CSI 드라이버를 설치하면 볼륨 사용 가능
- vSphere Cloud Config Spec : vSphere Cloud provider를 위한 요구사항 파일. 요약하면 설정 파일.
- --cloud-config 플래그로 던짐
- vSphere 7버전부터 네이티브하게 지원하므로, 회사에 라이센스 비용이 충분하다면 7으로 바로 고고.
Tutorial 따라가기
클러스터
도커 런타임 설치
sudo yum updatesudo yum install ca-certificates software-properties-common apt-transport-https curl -ycurl -fsSL https://download/docker.com/linux/centos/gpg |
kubernetes adm and cli 설치
govc 설치
vCenter 관리용 CLI 도구. govc는 go로 vc(enter)를 관리한다는 의미인 듯? 간단한 폴더 생성부터 호스트 관리같이 웹 인터페이스를 통해 하는 많은 작업들을 cli로 진행할 수 있다.
기본 접속 정보
# 기본 설정 정보. vcenter 주소 및 접속정보export GOVC_URL=myvc.donga.ac.krexport GOVC_USERNAME=vcenteruseridexport GOVC_PASSWORD=vcenter user passwordexport GOVC_INSECURE=true#접속 테스트$ govc about
govc about으로 기본 vCenter 정보를 가져올 수 있으면 vCenter SDK가 정상동작하고 있는 것이다. 접속 체크를 할 때 다음과 같은 에러 메세지가 뜰 수 있다.
govc: Put https://vcenterip/sdk: dial tcp vcenterip:443: i/o timeout
위와 같은 메세지가 뜬다면, govc를 동작하고 있는 호스트에서 vcenter방향의 443 통신이 정상동작하는지 확인하자.
kubernetes node용 VM 설정 변경
- disk UUID enable
$ govc vm.change -vm [vmpath] -e='disk.enableUUID=1'ex) govc vm.chagne -vm /DataCenter/vm/kube-dev/kube-node-01 -e="disk.enableUUID=1"
- VM 하드웨어 버전 업데이트: 버전 15이상
$ govc vm.change -hwgovc vm.info '/Datacenter/vm/kube-dev/kube-node-01' | grep HwVersion>> HwVersion : 15
???? 되는건가????
- Disable Swap
중지! 중지!
현재 ESXi에서 HwVersion을 14까지밖에 지원하지 않는다! 잠시 중지 중지!!