KUBIC Administrator Manual
1.1. KUBIC 개요
KUBIC(UCIM)은 Kubenetes API를 이용한 Enterprise Container 관리툴입니다.
1.1.1. KUBIC 구성도
위의 구성은 kubenetes minion 2대의 구성예입니다.
- ucim-manager
- nginx : 관리자 웹 접속 (quasar, vuejs)
- uwsgi : ucim api (flask)
- kube-master
- kube-apiserver, kube-scheduler, kube-controller : kubenetes 컨트롤 데몬(인증, API 처리, pods 스케쥴링/제어 등)
- etcd : ucim-manager와 kubenetes를 위한 key-value store
- registry : docker image 저장소
- kube-minions
- kubelet : pods를 제어하는 kubenetes의 agent
- kube-proxy : pods의 서비스를 위한 네트워크 프록시(부하분산 등)
- service containers : 서비스를 위한 pods 구동
1.1.2. UCIM 관리자 페이지 개요
| 번호 | 이름 | 설명 |
|---|---|---|
| ① | 콘솔 | 관리/테스트용 접속 콘솔입니다. 설치시 생성한 kubicshell의 container로 구동됩니다. |
| ② | 대시보드 | UCIM cluster의 정보를 확인할 수 있습니다. |
| ③ | 호스트 | 호스트 상세정보 보기, 모니터링 기능을 제공합니다. |
| ④ | IP POOL | IP POOL 등록, IP 삭제 기능을 제공합니다. |
| ⑤ | 프로젝트 | 프로젝트 생성, 삭제 기능을 제공합니다. |
| ⑥ | 레지스트리 | 레지스트리 등록, 수정, 삭제, 이미지 보기 기능을 제공합니다. |
| ⑦ | 이미지 | 이미지 생성, 로그 보기, 로그 삭제 기능을 제공합니다. |
| ⑧ | 카탈로그 | 카탈로그 생성, 수정, 매니페스트 수정, 삭제, 앱 생성 기능을 제공합니다. |
| ⑨ | 앱 | 앱 상세보기, 매니페스트, 삭제, 실행, 정지, 스케일, 롤링 업데이트 기능을 제공합니다. |
| ⑩ | 사용자 | 일반 사용자 계정 상세보기, 수정, 비밀번호 변경, 삭제 기능을 제공합니다. |
| ⑪ | 비밀번호 | 관리자 계정(admin)의 비밀번호를 변경합니다. |
| ⑫ | 로그아웃 | 관리자 계정(admin)을 로그아웃합니다. |
1.1.3. UCIM 관리순서
ucim을 처음 설치한 상태라면 ② 대시보드와 ③ 호스트의 정보가 정상적으로 출력되어야합니다. 정상적으로 나타난다면 ④ IP POOL부터 ⑨ 앱까지 순차적으로 설정을 진행하면 됩니다.
그리고 각 섹션의 스크린샷에도 번호를 부여했습니다. 이 번호의 순서대로 클릭, 설정하면 됩니다.
1.2. 로그인
웹부라우저를 켜고 ucim-manager의 서비스 IP로 접속을 시도합니다.
http://[ucim-manager-service-ip]을 입력하면 아래와 같이 사용자로그인 화면이 출력됩니다.
관리자로 로그인하기 위해서 ‘관리자 로그인’ 버튼을 클릭합니다.
관리자 계정의 ID는 admin입니다. admin 계정의 비밀번호는 “UCIM 설치”에서 설정하였으므로 해당 매뉴얼을 참고해주세요.
로그인에 성공하면 아래와 같은 메인화면(대시보드)을 볼 수 있습니다.
1.3. 콘솔
ucim 설치시 생성한 기본 docker image의 container의 콘솔입니다. 서비스에 대한 관리/테스트 용도로 사용할 수 있습니다.
엔터키를 누릅니다.
콘솔이 나타났습니다. 현재 접속한 콘솔의 호스트네임은 e07ff77c51e3이지만 나중에 다시 콘솔에 접속할 때는 호스트네임이 변경됩니다. 이는 Container의 ID로, 새로 접속할때마다 새로운 container가 구동되어 연결됩니다. 따라서 추가 package를 설치하기 위해선, docker image 를 재생성해야합니다.
위 기본 docker image시 생성한대로 vim, ssh, dig 등을 포함하고 있습니다.
1.4. 대시보드
대시보드에서는 ucim-cluster(minion)들의 정보와 그의 총 사용량을 보여줍니다. 미니언 1개당 코어를 1개로 설정했기 때문에 전체 코어 개수는 2코어가 됩니다. 앱 상세보기에서 미니언들의 상세 정보를 확인할 수 있습니다.
- 이름 : 등록된 cluster의 이름
- 매스터 URL : kubenetes master서버의 API URL
- 설명 : cluster의 description
- 호스트 : kubernetes minions의 수
- 프로젝트 : kubernentes namespace 수
- 앱 : 현재 구동중인 앱
처음 설치시 앱(pods)은 기본적으로 3개로 kubedns, prometheus, grafana로 구성됩니다.
이어 시스템 수치들이 그래프로 출력됩니다. 트래픽은 RX/TX가 각각 양수, 음수로 표시되어집니다. Cluster filesystem usage의 Used와 Total이 N/A로 표시되는 것은 CentOS의 Docker Storage Type과 연관되어 있습니다. 현재 devicemapper의 lvm은 위와 같이 not available로 표시됩니다. debian계열의 aufs등 filesystem이라면 정상적으로 표시됩니다.
1.5. 호스트
kubernetes minion으로 등록한 호스트(nodes)들의 정보를 볼수 있습니다.
1.5.1. 호스트 상세보기
호스트(minion)에 대한 상세한 정보를 확인할 수 있습니다.
1.5.2. 호스트 모니터링
호스트에 대한 시스템 정보를 realtime으로 확인할 수 있습니다.
1.6. IP POOL
앱(pods)를 생성하고 실질적인 서비스를 하기 위해선 서비스 IP(공인IP)가 필요합니다. IP POOL에서 해당 호스트(minion)에 대한 서비스 IP를 할당합니다.
1.7. 프로젝트
프로젝트는 kubernetes의 namespace로, 사용하고자 하는 목적이나 팀/서비스종류에 따라 Pods를 구분할수 있습니다.
1.7.1. 프로젝트 생성
생성버튼을 눌러 등록합니다.
1.7.2. 프로젝트 삭제
프로젝트를 삭제하려면 먼저 실행 중인 Pods를 종료해야 합니다. 아래와 같이 실행 중인 Pods가 있을 경우 프로젝트를 삭제할 수 없습니다.
“앱 삭제” 후 Pods를 종료했다면 아래와 같이 프로젝트를 삭제합니다.
프로젝트 목록에서 dns 프로젝트가 삭제되었습니다.
1.8. 레지스트리
레지스트리는 docker image가 저장되는 일종의 repository입니다.
1.8.1. 레지스트리 등록
ucim에서 registory는 기본으로 kubernetes master에서 container로 구동되어 있습니다. 따라서 kubentes master의 ip로 등록이 가능합니다. port는 5000을 사용합니다.
Registry 라는 레지스트리가 등록되었습니다.
1.8.2. 레지스트리 수정
레지스트리 설명을 아래와 같이 수정해보겠습니다.
- Private
+ Private(Local repository)
레지스트리 설명이 ‘Private(Local repository)’로 수정되었습니다.
1.8.3. 레지스트리 삭제
레지스트리가 삭제되었습니다.
1.8.4. 레지스트리 이미지 보기
레지스트리에 등록되어 있는 이미지들을 볼수 있습니다. kubernetes에서 pods 구동시 필요한 pause container가 기본으로 등록되어 있음을 확인할수 있습니다.
1.9. 이미지
1.9.1. 이미지 생성
ucim에서 이미지 생성은 등록되어 있는 이미지를 기반으로 자동으로 처리됩니다.
아래와 같이 bind 이미지를 선택하고, 버전을 입력하면 이미 등록된 dockerfile을 기반으로 bind이미지가 자동으로 생성됩니다. 필요한 packages의 설치와 선택한 버전의 bind source 가져와 compile하고 build하는 작업이 백그라운드로 진행되게 됩니다.
생성할 이미지가 저장될 레지스트리를 선택합니다. 여러개의 레지스트리를 구성하였다면, 하나를 선택할수 있습니다.
bind 이미지가 생성되었습니다.
1.9.2. 이미지 로그 보기
이미지가 생성되는 과정을 지켜볼수 있는 로그를 출력합니다.
이미지생성이 완료되었을 경우 아래와 같이 “*** Build Complete! ***”이란 메시지를 확인할수 있습니다.
1.9.3. 이미지 삭제
등록된 이미지를 삭제할수 있습니다. 다만, 레지스트리에 push된 이미지는 따로 삭제가 불가능합니다. (현재 docker registry api 미지원)
1.10. 카탈로그
UCIM은 이미지로부터 앱(pod)를 생성하기전 그에 대한 자원/노드/IP/포트 정의해 카탈로그에 저장합니다. 이 카탈로그를 이용하여 앱(pod)를 생성할수 있습니다.
1.10.1. 카탈로그 생성
이름과 등록할 레지스트리, 이미지를 먼저 설정합니다. 매니페스트 파일은 kunetenes에서 사용하는 yaml형식의 manifest파일입니다. jinja format으로 구성된 이 yaml은 앱을 생성하게되면 그 설정에 맞게 실제적인 yaml로 재생성되게 됩니다.
bind image에서 사용하는 sample을 ucim-manager 서버의 /home/ucim/kubic/kubic/template/bind_catalog_sample.j2에 올려두었습니다. 이를 복사해 넣으시면 됩니다.
bind 카탈로그가 생성되었습니다.
1.10.2. 카탈로그 수정
등록된 카탈로그의 이미지와 설명을 수정할수 있습니다.
1.10.3. 카탈로그 매니페스트 수정
매니페스트를 수정할수 있습니다.
1.10.4. 카탈로그 삭제
등록된 카탈로그를 삭제할수 있습니다.
bind 카탈로그가 삭제되었습니다.
1.10.5. 파일 관리
App에서 사용할 파일들을 관리/배포할수 있습니다. 일반적으로 앱에서 사용할 설정파일들을 이곳에 저장해두고 앱에 적용할 용도로 사용됩니다. “파일관리 콘솔”를 실행하면 container가 실행되고 shell이 떨어집니다. 이 container의 /data 디렉토리에 파일을 넣어둡니다. 위에서 등록한 bind가 사용하는 설정파일들을 복사합니다. 샘플로 설정파일을 링크합니다. 해당 파일을 압축을 풀어 /data 디렉토리에 풀어놓습니다. “파일 배포”를 통해 변경된 파일을 다른 앱에도 배포할 수 있습니다.
1.10.5.1. 관리 콘솔
관리 콘솔을 누르면 컨테이너가 실행됩니다. 컨테이너의 /data 디렉토리에는 위에서 압축을 해제한 설정파일이 있습니다.
엔터키를 누릅니다.
관리 콘솔에 접속했습니다.
/data 디렉토리에서 설정 파일들을 확인할 수 있습니다.
1.10.5.2. 파일 배포
컨테이너의 /data 디렉토리 밑에 있는 설정 파일을 업데이트했다면 다른 앱들에도 변경된 설정파일을 적용하기 위해서 파일 배포를 실행합니다.
파일 배포가 완료되었습니다.
1.10.6. 일괄 명령 실행
해당 카탈로그로 생성된 앱들에게 일괄적으로 Command를 날려 실행할수 있습니다.
1.10.7. 앱 생성
이제 실직적인 서비스들 담당하는 앱을 생성할 차례입니다. 카탈로그’ 메뉴의 ‘앱 생성’ 버튼을 누르면 앱이 생성됩니다. (앱 메뉴에는 앱을 생성할 수 없습니다)
사용할 앱의 이름과 프로젝트, 이미지를 선택합니다.
앱에서 구동할 Container의 수와 자원을 설정합니다. CPU 단위는 millicore이며 (1 core = 1000 millicore), CPU와 메모리를 지정하지 않는다면 자원의 제한없이 구동됩니다.
서비스할 포트와 호스트, 서비스IP를 설정합니다. DNS는 port 53을 사용하므로 53으로 설정합니다.
확인을 눌러 앱을 생성합니다.
생성된앱은 Halt된 상태입니다.
1.11. 앱
1.11.1. 앱 상세보기
등록된 앱에 대한 정보를 볼수 있습니다.
1.11.2. 앱 매니페스트
카탈로그 매니페스트 파일에서 앱설정에 대한 jinja template이 적용되어진, 앱에 대한 매니페스트파일을 볼수 있습니다.
1.11.3. 앱 수정
현재 앱 수정 불가능합니다.
1.11.4. 앱 삭제
등록된 앱을 삭제합니다. 아래처럼 앱이 실행 중인 경우에는 앱을 삭제할 수 없습니다. 앱을 정지한 후 삭제해야 합니다.
아래와 같이 앱을 정지합니다.
앱이 Run 상태에서 Halt 상태로 변경되었습니다.
앱이 정지되었으므로 앱을 삭제합니다.
앱(bind-9-10-5)이 삭제되었습니다.
1.11.5. 앱 기능
1.11.5.1. 실행
앱을 실행합니다.
앱(bind)이 실행되었습니다.
상태값이 “Running”인지 확인합니다. 만약 상태가 “Pending”에서 “Running” 넘어가지 않고 다른 상태가 표시되거나, 재시작의 숫자가 지속적으로 높아져간다면 제대로 앱이 실행되지 않음을 의미합니다. 이때는 이미지는 정상적으로 생성되었는지, 설정파일들은 옳바른지 다시 한번 확인합니다.
앱이 실행되었으니 실질적인 bind서비스가 정상 작동하는 확인해봅시다. 서비스 IP로 dns query를 날려 정상적으로 서비스되는지 확인합니다. (상단 메뉴의 ‘콘솔’을 이용해도 됩니다.)
$ dig bh.go.kr @192.168.0.113
; <<>> DiG 9.11.1 <<>> bh.go.kr @192.168.0.113
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25014
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 15, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: d4a366f970704f00169762975939160c5234aa3921714288 (good)
;; QUESTION SECTION:
;bh.go.kr. IN A
;; ANSWER SECTION:
bh.go.kr. 300 IN A 114.111.58.162
bh.go.kr. 300 IN A 61.110.219.64
bh.go.kr. 300 IN A 114.111.58.181
bh.go.kr. 300 IN A 174.35.47.46
bh.go.kr. 300 IN A 61.110.219.59
bh.go.kr. 300 IN A 101.79.161.191
bh.go.kr. 300 IN A 101.79.162.201
bh.go.kr. 300 IN A 101.79.161.211
bh.go.kr. 300 IN A 174.35.44.70
bh.go.kr. 300 IN A 101.79.162.192
bh.go.kr. 300 IN A 101.79.161.202
bh.go.kr. 300 IN A 174.35.47.36
bh.go.kr. 300 IN A 114.111.57.112
bh.go.kr. 300 IN A 174.35.44.65
bh.go.kr. 300 IN A 114.111.57.132
;; AUTHORITY SECTION:
bh.go.kr. 43200 IN NS nis.dacom.co.kr.
;; Query time: 1 msec
;; SERVER: 192.168.0.113#53(192.168.0.113)
;; WHEN: 목 6월 08 18:17:00 KST 2017
;; MSG SIZE rcvd: 332
1.11.5.2. 정지
앱의 구동을 정지시킬수 있습니다.
1.11.5.3. 스케일
스케일 기능(scale up, scale down)을 이용하면 앱의 Container의 개수를 라이브로 조절할 수 있습니다. 예를들어 Replicas를 1개에서 2개로 변경한다면, 1개로만 구동중인 container가 2개의 container로 구동되어집니다.
앱(bind)를 scale up(1개 -> 2개) 하였습니다.
복제 개수는 2개가 되었습니다.
1.11.5.4. 롤링 업데이트
롤링 업데이트 기능을 이용하면 bind 태그가 9.10.5로 구동 중인 앱(VM)을 bind 최신 태그(bind v9.11.1)로 변경하여 라이브로 앱을 업데이트 할 수 있습니다. 롤링 업데이트 진행 순서는 다음과 같습니다.
1. bind 최신 이미지(태그) 9.11.1 생성
2. bind 태그가 9.11.1인 신버전의 앱(VM) 실행
3. 정상적으로 실행되어 되었다면 bind 태그가 9.10.5인 구버전의 앱(VM) 종료
(반대로, 최신버전에서 구버전으로의 롤링 업데이트 역시 가능합니다.)
현재 사용 중인 태그(9.10.5) 보다 상위 태그인 9.11.1을 선택합니다.
롤링 업데이트를 성공하였습니다.
태그가 9.11.1로 변경되었습니다.
1.11.5.5. 재부하 분산
앱의 서비스 IP를 동적으로 추가/변경/재설정하여 네트워크의 부하를 분산할 수 있습니다.
재부하분산을 위해 192.168.0.114 IP를 추가로 선택합니다.
재부하분산이 완료되었습니다. 이제 bind 앱의 외부 IP는 ["192.168.0.113", "192.168.0.114"]로 보이게 되고, 실제 서비스 역시 2개의 IP로 이뤄지게 됩니다.
1.12. 사용자
사용자 메뉴는 아래와 같이 구성되어 있습니다.
1.12.1. 사용자 생성
1.12.2. 사용자 상세보기
1.12.3. 사용자 수정
사용자의 설명을 수정하였습니다.
- 테스트 계정
+ 테스트 계정입니다~~!
1.12.4. 사용자 비밀번호 변경
관리자/사용자의 계정 비밀번호를 변경할수 있습니다.
1.12.5. 사용자 삭제
사용자(iorchard)가 삭제되었습니다.
1.13. 비밀번호
비밀번호 탭에서 관리자 계정(admin)의 비밀번호를 변경할 수 있습니다.
관리자 비밀번호가 변경되어 로그아웃되었습니다.
1.14. 로그아웃
관리자/사용자의 세션을 종료하고 로그아웃합니다.
