4. 주요 기능

전체적인 클러스터의 메트릭 현황을 제공하는 대시보드이다.

[그림 4.4] K8s Cluster Summary

프로메테우스의 Node Exporter에서 제공하는 하드웨어의 상태와 커널과 관련한 메트릭 정보를 제공하는 대시보드이다.

[그림 4.5] Node Export Info

클러스터 기준에 각각의 노드의 메트릭 정보를 제공하는 대시보드이다.

[그림 4.6] K8s All in One

[클러스터 조회/변경] > [기본 설정]에서는 시스템 구분 항목의 값이 주요한 정보로 주로 애플리케이션 배포 프로세스에 관여한다. 설정에 따라서 미세하게 다른 동작을 하겠지만 일반적으로 Development 시스템 구분은 Gitlab에 웹훅을 통하여 젠킨스의 CI/CD 파이프라인이 실행되어서 BXCP ADM에서 제공하는 배포 REST API가 호출이 되며, Staging(또는 Production) 시스템 구분은 BXCP ADM의 배포 REST API 호출을 BXCP ADM에서 자체적으로 호출이 이루어진다.

[그림 4.11] 클러스터 조회/변경 - 기본 설정

아래 그림은 [클러스터 조회/변경] > [KUBECONFIG 설정] 탭 화면으로 쿠버네티스 클러스터에 연결을 하기 위한 환경설정을 지정하는 화면이다. 관리자 권한으로 쿠버네티스 연결이 필요한 다른 사용자가 쿠버네티스 설정이 필요하면 이 화면에서 제공하는 값을 사용해서 kubectl 커맨드를 사용할 수 있다.

[그림 4.12] 클러스터 조회/변경 - KUBECONFIG 설정

쿠버네티스 클러스터와 상호작용 하는 BXCP ADM에서 쿠버네티스 연결 설정이 필요하기 때문에 관리자는 다음과 같이 해당 클러스터에 kubectl 커맨드를 사용하는 환경에서 연결 설정을 확인하여 입력한다.

$ kubectl config view --raw=true
apiVersion: v1
clusters:
- cluster:
    certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUMvakNDQWVhZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXS
	mwKY201bGRHVnpNQjRYRFRJeU1URXdPREF4TWpnMU5sb1hEVE15TVRFd05UQXhNamcxTmxvd0ZURVRNQkVHQTFVRQpBeE1LYTNWaVpYSnVaWFJsY3pDQ0FTSX
	dEUVlKS29aSWh2Y05BUUVCQlFBRGdnRVBBRENDQVFvQ2dnRUJBSzcrCnJQaHhiUkZ2NnRMaXlGSUFpS0FpM1RIQ0RsTGxLUy9pajM3dnVxNHpRSkM2TzR2V0d
	henRZQ1JETlI0SU00RHgKQ05qMnhZaXNkazB0MUNwQnh0MSttSzVWWkZUbHJSMStNTXJWY3VPcUNsZWxBNHg3S29JbDRhc1R4WXQ0bHdvOQpXSDM0c3pjSE10
	VXhZUzhycXIvRThpL3FPWlRYdFRCNEV0RGNzU0pQZHFHVjdFamVnQXRRbDFJMmt6bWprTVVFClV1UmsxeEVUd2tKODh4bnFuWGZpNWxHMWR3aTFiaHJqdStTK
	2lPLzZoVWJPaUVDRE04cnV0NlFSa0RmSFEyM3UKSHVES3JpT0JaMDZIOEJsUGF2NDM0SGRLUlBuK0thcU50aHhabkxWNmVPVHhPQzZPZ1MzcFlkNFR5ak5ENT
	B2QwpaeGpnNjVpRUIvMEF3VFhaWHdFQ0F3RUFBYU5aTUZjd0RnWURWUjBQQVFIL0JBUURBZ0trTUE4R0ExVWRFd0VCCi93UUZNQU1CQWY4d0hRWURWUjBPQkJ
	ZRUZQNEMybnllcVFsbThmc25jOWdHWkwrQlJqRi9NQlVHQTFVZEVRUU8KTUF5Q0NtdDFZbVZ5Ym1WMFpYTXdEUVlKS29aSWh2Y05BUUVMQlFBRGdnRUJBRlFD
	enBpakllSEtGZ3dBdFRRSQp3WTdSRTU2K1o1RTNxbnBQRlRFWnhwNWxJd3g4bUIzNElNU1dqZzY4SVFoT0wwQ3ZtUDFENDdQbGNlZjB0allaCllGbUVKMjA1c
	lBpcWZQbU40SXNIYzBDY2VzL3NueUVrTU0xQWtmZS8zQUN1VktBc0hkS2pjTjBzQ0s3Uk5GcEEKK1doa2hvK0puTnF6S1JxalhaRkNVdTV5cUprU1NqNGFRel
	VwMmx1ZUNXRk1DMEVLZkxiMGlzOFZVWW5yRy9SZApNY2psZ0o3TXRIVzRHdjVXaWxsYzZTaHlsSGFmWXRzTWpBeE9rSnY4RFI3K1NwNzJoMm5oV2lXV2ZxbHp
	XOUYyCjRZSjcyeUY3QmdqcytXNU5hc2pBVGgxYVhHcmh1RHhtcHgyUGZjUzY1UEp3VTcvSHVlQ1dvUVo4V0xvRDNrNkoKc2w4PQotLS0tLUVORCBDRVJUSUZJ
	Q0FURS0tLS0tCg==
    server: https://tf-k8s-lb-host-host-eb247e47fda94245.elb.ap-northeast-2.amazonaws.com:6443
  name: kubernetes
contexts:
- context:
    cluster: kubernetes
    user: kubernetes-admin
  name: kubernetes-admin@kubernetes
current-context: kubernetes-admin@kubernetes
kind: Config
preferences: {}
users:
- name: kubernetes-admin
  user:
    client-certificate-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSURJVENDQWdtZ0F3SUJBZ0lJQU9JaEg5R1hQUWN3RFFZSktvWklodmNOQVFFTEJRQXdGVEVUTUJFR0ExV
	UUKQXhNS2EzVmlaWEp1WlhSbGN6QWVGdzB5TWpFeE1EZ3dNVEk0TlRaYUZ3MHlNekV4TURnd01USTROVGhhTURReApGekFWQmdOVkJBb1REbk41YzNSbGJUcH
	RZWE4wWlhKek1Sa3dGd1lEVlFRREV4QnJkV0psY201bGRHVnpMV0ZrCmJXbHVNSUlCSWpBTkJna3Foa2lHOXcwQkFRRUZBQU9DQVE4QU1JSUJDZ0tDQVFFQXp
	vOEhETWlEWjRSWnAvR2oKcjVBcXEzbnB1cXF5aHl5M1F6clVYTkQyRnBBSXBwVm5KV0Q2VjJnT0wybVI4MDlNQ29IMERQSHhkcDJ0b2pUNQpzYXpCbFFzeHAv
	U2NQQ2xuRWN5SHpIaW1jVDdEelczVW5TbExrclpsRGU1RHpWWVlRbzA2MVZtbnJoTmo1V1FpCjJmYWtkZDRNNm9uakh1NENheDFTVkl2QUdtdkFwcVFRV0lwT
	nNMOEwxTkJlWDdITm13RlRNQ1k2QW9MR2FiQ2MKRDNVcXpKYlp3c0RIUnRrSStaNmFUTUpvMzdtSDdIUWdGRnlSRklwcG82ZThvQkJGK2xNemtiR2FSODZOaW
	VXUQpjY0hZYmtyUTZ4c3A3Q0dkY1N2eHlKS3lKcnNiNHZla0pIQmxVS3RjL0tzaG9Cc1BRckZUNDA5My8xSDVKSmdPClpTeUNad0lEQVFBQm8xWXdWREFPQmd
	OVkhROEJBZjhFQkFNQ0JhQXdFd1lEVlIwbEJBd3dDZ1lJS3dZQkJRVUgKQXdJd0RBWURWUjBUQVFIL0JBSXdBREFmQmdOVkhTTUVHREFXZ0JUK0F0cDhucWtK
	WnZIN0ozUFlCbVMvZ1VZeApmekFOQmdrcWhraUc5dzBCQVFzRkFBT0NBUUVBRlltNm92eEhiTHpmdHdBNTF0THhYVVBURkZiTXFyVnIvZDZBCkF4S3pqU2g4d
	zRVTCt6WUNnNHQ2V0R6eU9ydVVFTHppYm9IRFBxQzN0SnY0c29DODE4RFJZZ3F5Wk5JVDRjUlcKcmhibDFNNXQ2WEN4cEMxRmlUVTRyRDVyczUzRTFxcFYxaV
	NJQzBVdjdkUjBzemlHK3YxL0FvRzNxcWdHNktGawozWE9Mb01zNUg2NGlxSlJiTGVvRmRMRk9wSHMvc3F0OWN0WkJsWEZWdmVoUnVEampBTkdZci9DU1R1U0F
	SRE5tClZFSklXYXFoeUhRVllib01iMmVvU25MMFZlOGVDVFFRRTBzcloxVm9zQ3BWK3FqNVBocmlIdGcwWkdpK2pzdS8KSUNPanR3NG1mbDYvYlRsZHJ4VVFa
	M0xnSkFZQTJRWVo5RjBDNU4wdTI1c2lLcVNWbkE9PQotLS0tLUVORCBDRVJUSUZJQ0FURS0tLS0tCg==
    client-key-data: LS0tLS1CRUdJTiBSU0EgUFJJVkFURSBLRVktLS0tLQpNSUlFb3dJQkFBS0NBUUVBem84SERNaURaNFJacC9HanI1QXFxM25wdXFxeWh5eTNRenJVWE5EMkZwQ
	UlwcFZuCkpXRDZWMmdPTDJtUjgwOU1Db0gwRFBIeGRwMnRvalQ1c2F6QmxRc3hwL1NjUENsbkVjeUh6SGltY1Q3RHpXM1UKblNsTGtyWmxEZTVEelZZWVFvMD
	YxVm1ucmhOajVXUWkyZmFrZGQ0TTZvbmpIdTRDYXgxU1ZJdkFHbXZBcHFRUQpXSXBOc0w4TDFOQmVYN0hObXdGVE1DWTZBb0xHYWJDY0QzVXF6SmJad3NESFJ
	0a0krWjZhVE1KbzM3bUg3SFFnCkZGeVJGSXBwbzZlOG9CQkYrbE16a2JHYVI4Nk5pZVdRY2NIWWJrclE2eHNwN0NHZGNTdnh5Skt5SnJzYjR2ZWsKSkhCbFVL
	dGMvS3Nob0JzUFFyRlQ0MDkzLzFINUpKZ09aU3lDWndJREFRQUJBb0lCQVFDd1RzN2lyMmZSL05zVwpDYUFBbzVwNFFSZ3FkN2Jvd0Zjd3NFOUJaaThXOVJ3Z
	ExGc2RRWmlNOE1saTJNWjJHcEk2U2RBSkdKNVU4Nk9ZClY0VmxqYUt5V0JxclZKUGltaWhhdmV5UHI4L0p5NXdQaFphOEN0cHh3UE9pbjJRS0tWbU52TVNpQk
	9PbUp2RFcKaE5GbW9DcWlYTVZEa0N4bll4cDNXVkREejRGS1NuTzZDOVY1VXo4bnpaNHI5dzBXK1ZJMTQ4amZyeWJjU1BFdQoxdzRlV3lFdWpPUExWMHRDWG5
	jMnc5cHdBNVk4clhBRVZvbThveDY2R3BQZXJja1RjZVdkT2RCQWhiZWlZcjVpCk52VkV5akFXZFVIM0dka04ybnFCTnRpOE9Tdis2ZjRSemg2YnAraW1rSFZS
	OTJPbUJDK0d2UzhhVzg2TlpGMEgKRm9VbmYxMWhBb0dCQU5sdk56WGhZVy9iSGlaWTcxQzg0TXFQZHdqaUpoQXdsc1F5eHR1VUgzTmV1ZmhHR3ZnbgpvejUwc
	1RpMzkxd1ZnM2FvbmlMS0xDNHlsOU42U1lSMnFwdEYzWWpiOG1IRG40cTlZdW9iUmZCaDNSM2M1UUxYCloraFloWGVkMTFmQmpFRmRoRE52MUltNUpGN2FhOV
	BjYTJyVEZpYkdvazBRalJNb21mQUoyZnl4QW9HQkFQTXgKL1kxNG5jQWlJaWx6TzdZMmNNWU40MDZodjdjL1c4eVVkb3AxdkpzR1dta0dob1dmSmt3WmJueEd
	xMG5iT1NUcApuU3NXK1pyY092THR6R2I1Q0tIMFNoeGxTekxsWW9yYkdBUmhORmRPcnlyc2d2MXNXUHFMZGpYRFVJR3U4TzRqCkFKUmNncStrZHQ3YlM3K3hQ
	bkUza3VsMDEybTVpV09zYVMvdlJWYVhBb0dBTXlqVDJMMmE2M0ttK1diYmlDZW8KeklCTkJhNFFQcWJ3RW1IUUlFSU4xRnRwYmwwd1kwc1FRZFc3RFJsYi9qS
	2hwLzJzbDRyeU1qeDlOS2tGTzBHZwppc0E1aThZVWxhUXRtYnROMXI5c0NVODljNVZSM1FWSjBZVmlnZTZGaUlSbHQ4dUZHNFVvZ084cSs1Wnc0SHh3CldjWW
	81QjdBZVZsM21CWnBnZTBQZVVFQ2dZQnF0alBRNE8wdmdvckU3Mmh6SXQ1SE9ZN1ZVUXBEeVV4cHIzZDQKZUFNamJ4MDYybjhxb05QNExteVpvWlRGbXFrdmR
	rYmR3bjRTSXJMSEorczUvK3AyemkrNjJBT3dPSkVONXVkWgovS0V2OGpuUXR1a2ZkR3h5dThGS0JBTU9kSW9KcEZnN3dZQWl2Q0xnMVE4ZTlSSTJNYkdJT1Ju
	UXJYWUl3MzJBCmFCaGZ6d0tCZ0VEQ0t1cDJJa0JmUDdMdXVHMXBZYkM4YjZKR0dUVGludzJoOUFkTEVhb3R5QUp4L1RzQUtSVkEKcUkxUGNVbHJPYm5odmpwQ
	mlIbmJaWUdzdi9URDdtZVdaRjhWUU05WThZNTBCNnVWVkFEc3cydy9LL3JsajVxcwo4NHIrWEFCdGpGMXNEZ0hvOFN0VGh0WTc3aGtQSVI4MFplZVFjRS9KQl
	RrN3BKK1B6T3FNCi0tLS0tRU5EIFJTQSBQUklWQVRFIEtFWS0tLS0tCg==

경고

화면에서 설정 값을 변경 할 수 있기 때문에 수정을 완료하면 [저장] 버튼을 누르기 전에 반드시 [설정 정보 검증] 버튼으로 올바르게 수정하였는지 검증한다. 아래 2개 그림은 설정 검증의 성공과 실패의 예시를 보여준다.

[그림 4.13] 클러스터 조회/변경 - KUBECONFIG 설정 - 검증 성공

[그림 4.14] 클러스터 조회/변경 - KUBECONFIG 설정 - 검증 실패

아래 그림은 [클러스터 조회/변경] > [컴포넌트 설정] 탭 화면으로 이 화면에서는 BXCP ADM과 연동하여 동작하는 3rd Party 컴포넌트의 주소나 값을 설정하는 화면이다.

컴포넌트 설정에서는 연동하는 다른 시스템에 문제가 있거나 혹은 컴포넌트를 호스팅하는 서버를 변경하는 등의 다양한 상황에서 연결 정보를 조정하는 기능이 제공된다. 이 화면에 설정에 오타나 해당 3rd Party 컴포넌트에 문제가 있으면 BXCP ADM에서 일부 기능에 문제가 발생할 수 있다.

[그림 4.15] 클러스터 조회/변경 - 컴포넌트 설정

위 그림에 나온 번호를 보면 해당 설정이 어떤 메뉴에 영향이 있는지 표시한 것이다.

1. Grafana URL

[대시보드] 메뉴를 클릭하면 보이는 사전 정의된 Grafana 대시보드에 연결하는 Base URL 정보이며 아래 그림과 같이 보인다.

[그림 4.16] 대시보드 선택 팝업

2. Jaeger, Kiali, Kibana URL

[모니터링] 메뉴를 클릭하면 보이는 사전 정의된 모니터링에 관련된 오픈소스 컴포넌트에 연결하는 Base URL 정보이며 아래 그림이 메뉴 클릭 시 보이는 팝업이다.

[그림 4.17] 모니터링 선택 팝업

아래 그림은 [클러스터 조회/변경] > [컨테이너 레지스터 재정의] 탭 화면으로 컨테이너 이미지 저장소 주소를 재정의 할 수 있는 화면이며, 현재 BXCP ADM에서는 Harbor Registry를 사용하고 있다.

클러스터를 기준으로 재정의 값을 설정하면 클러스터가 포함하는 모든 프로젝트는 이 정보를 사용하게 된다. 의존성이 강한 정보이기 때문에 유의한다.

[그림 4.18] 클러스터 조회/변경 - 컨테이너 레지스터 재정의

아래 그림은 [클러스터 조회/변경] > [DASHBOARD 설정] 탭 화면으로 이 화면에서는 클러스터를 기준으로 사용할 Grafana 대시보드를 설정하는 역할을 한다.

[그림 4.19] 클러스터 조회/변경 - DASHBOARD 설정

아래 그림은 설정된 대시보드의 상세 정보를 볼 수 있는데 이 팝업에서 중요한 설정은 대시보드 URL 항목에 값이다.

[그림 4.20] 설정된 대시보드 목록

위 그림을 기준으로 대시보드 URL 값을 보면 중간에 잘린 형태의(URI에서 Path 부분을 의미) URL 값이 설정된 것을 알 수 있다. 위에서 "Grafana에서 모니터링 할 대시보드를 구성해서 저장된 상태여야 한다."라고 언급한대로 대시보드 URL 값 설정을 위해서는 아래 그림처럼 브라우저에서 Grafana로 접속하여 원하는 대시보드로 이동해야 한다.

[그림 4.21] 설정된 Grafana 대시보드 접속

참고

위에 그림에는 일부 패널이 오류가 발생했다고 표시가 되어 있는데 아래 그림은 오류가 발생한 패널을 확대한 그림이다. 이렇게 오류가 발생한 패널은 사용자가(관리자) 확인하고 올바르게 동작하도록 패널에 설정을 수정해야 한다.

[그림 4.22] PromQL 오류

설정하고 싶은 Grafana 대시보드에 접속을 했다면 아래 그림처럼 HTTP 주소창에서 URL 경로 기준으로 grafana(빨간 화살표) 다음에 나오는 URL 경로를('/'부터) 복사해서 대시보드 URL 항목에 값으로 설정한다.

[그림 4.23] 설정된 Grafana 대시보드 접속 URL

현재 워크스페이스를 기준으로 BXCP ADM 사용자를 조회하여 이용자를 검색할 수 있다. 아래는 필터를 따로 사용하지 않고 조회한 워크스페이스에 속한 모든 사용자 정보 예시이다.

[그림 4.26] 사용자 설정 - 필터

특정 사용자가 해당 워크스페이스에 속하는지 아래 그림처럼 필터를 통해 조건에 맞는 사용자를 조회할 수 있다. 필터는 사용자 ID, 사용자 명, 부서, 역할을 선택할 수 있다.

[그림 4.27] 워크스페이스 조회/변경 - 사용자 설정 - 필터(부서)

아래 그림처럼 [변경] 버튼을 눌러서 사용자 검색 팝업 화면에서 워크스페이스에 사용자를 추가하거나, 제외시키는 처리가 가능하다.

[그림 4.28] 워크스페이스 조회/변경 - 사용자 설정 - 변경

아래 그림은 릴리즈 시스템 재정의 탭 화면인데 이 화면에서는 릴리즈 처리 과정에서 사용하는 중요한 설정을 할 수 있는 화면이다.

[그림 4.29] 워크스페이스 조회/변경 - 릴리즈 시스템 재정의

BXCP ADM에서 배포는 크게 두 가지 방식이 있는데 결과적으로는 모두 BXCP ADM의 배포 REST API를 호출하게 된다. 릴리즈 시스템 재정의 탭 화면에서는 릴리즈 이관 처리 과정에 관련된 값의 재정의를 할 수 있다.

아래 그림은 릴리즈 포탈에 대한 정보를 재정의 할 수 있는 항목이다. 이 릴리즈 포탈 정보는(릴리즈 Portal URL, 릴리즈 Portal Token) 이관 처리 시 사용하는 정보로 가져올 애플리케이션 정보가 같은(같은 URL 주소) BXCP ADM 환경에 있지 않고 원격지에서(다른 서버 주소) 가져올 때 이 정보를 재정의 해서 이용하게 된다.

[그림 4.30] 워크스페이스 조회/변경 - 릴리즈 포탈 정보

그리고 아래 그림은 온라인 애플리케이션을 생성 시 이관을 통해만 생성이 가능한 워크스페이스 환경에서(Staging 또는 Production 시스템 구분으로 설정된 상태) [온라인 애플리케이션] > [Create Application] 클릭하여서 조회된 이관할 수 있는 애플리케이션 목록 팝업이다. 예를 들어 아래 그림에 빨간 표시한 ratings 행을 클릭하면 이관이 진행된다.

[그림 4.31] Create Application - 이관 대상 애플리케이션 조회

아래 그림에 표시된 항목은 릴리즈 Harbor 관련 정보를 표시하고 있다. 설정할 속성에 이름을 보면 Harbor를 포함하기 때문에 컨테이너 이미지 처리에 대한 설정임을 알 수 있다. 즉 이 릴리즈 Harbor 정보는 [릴리즈] > [릴리즈 조회] > [릴리즈 이관] 버튼을 클릭하여 "배포를 위한 컨테이너 이미지를 가져올 때 이용하게 된다."

[그림 4.32] 워크스페이스 조회/변경 - 릴리즈 Harbor 정보

릴리즈 Harbor URL 속성의 값은 컨테이너 이미지를 가져올 Harbor Registry 서버 URL을 여기서 설정할 수 있다. 그리고 그 아래에 ID, Password 정보는 컨테이너 이미지를 pull 처리 시 인증을 요구할 때 이용하는 값이다.

릴리즈 Harbor 관련 재정의 속성을 지정하지 않으면 [환경설정] > [설정 관리] 화면의 값을 기준으로 작동하며 아래는 속성별 맵핑이다.

워크스페이스는 1개 이상의 클러스터를 하나의 논리적 작업영역으로 묶어주는 역할을 하기 때문에 아래 그림처럼 클러스터를 포함시키거나() 제외시키는() 처리를 가용 클러스터 설정 탭 화면에서 할 수 있다.

[그림 4.33] 가용 클러스터 설정

워크스페이스에서 가용 클러스터를 지정하여 워크스페이스가 포함하는 클러스터를 선택할 수 있고 이후에 설명하는 애플리케이션 스펙에서도 가용 클러스터를 상태에 맞게 설정을 할 수 있다.

프로젝트는 릴리즈 참조 프로젝트 ID 항목에 값을 설정할 수 있다. 아래 그림을 보면 이 정보를 설정한 프로젝트에서 애플리케이션을 생성하기 위해서 [온라인 애플리케이션] > [Create Application] 버튼을 사용 했을때 릴리즈 참조 프로젝트 ID 값을 설정한 프로젝트에서 이관을 하기 위한 애플리케이션을 조회하여 제공한다.

[그림 4.38] 이관 대상 애플리케이션 조회 결과

릴리즈 참조 프로젝트 항목에 값을 지정하지 않으면 필터링 되지 않고 이관을 할 수 있는 애플리케이션을 모두 조회하여 제공하게 된다.

[그림 4.39] 프로젝트 조회/변경 - 기본 설정

BXCP ADM에 프로젝트는 워크스페이스에 포함되는 논리적 단위이기 때문에 가용 클러스터 정보는 아래 그림처럼 일반적으로 워크스페이스에 설정된 기준으로 보이게 된다. 이 화면에서 워크스페이스에 설정된 기준을 재정의를 할 수 있는데 프로젝트에 클러스터를 포함하거나() 제외시키는() 재정의를 할 수 있다.

[그림 4.40] 프로젝트 조회/변경 - 가용 클러스터 설정

BXCP ADM에 프로젝트는 실질적으로 쿠버네티스 네임스페이스 리소스와 동일하다고 언급했는데, 이 가용 클러스터 설정 탭 화면에서 Resource Quota 버튼을 활성화 시켜서 값을 입력할 수 있고 [저장] 버튼을 누르면 쿠버네티스 환경에 ResourceQuota 리소스가 적용된다. 아래는 Resource Quota 정보를 입력하는 예시이다.

[그림 4.41] 프로젝트 조회/변경 - 가용 클러스터 설정 - Resource Quota

위에 그림에 표시된 부분에 원하는 값을 넣고 저장하게 되면 아래 그림처럼 ResourceQuota 리소스가 만들어지게 된다.

---
apiVersion: v1
kind: ResourceQuota
metadata:
  labels:
    kubefed.io/managed: "true"
  name: bookinfo-sta
  namespace: bookinfo-sta
spec:
  hard:
    limits.cpu: "1"
    limits.memory: 1000Mi
    requests.cpu: 100m
    requests.memory: 10Mi

그리고 가용 클러스터 설정에는 Limit Range 설정을 하는 항목이 있는데 아래 그림이 Limit Range 입력을 활성화한 상태를 보여준다. Limit Range 설정은 쿠버네티스의 LimitRange 리소스를 화면에 입력한 기준으로 생성한다.

[그림 4.43] 프로젝트 조회/변경 - 가용 클러스터 설정 - Limit Range

이 화면을 통해서 Limit Range 설정을 하면 다음과 같은 형태의 제약이 설정되는데 이것은 쿠버네티스 LimitRange 리소스의 기능이다.

빌드팩 정보를 설정 시 기본 설정 탭 화면에서는 애플리케이션 유형, 배포 유형 값을 지정하는 것이 핵심이다.

[그림 4.46] 빌드팩 조회/변경 - 기본 설정

애플리케이션 유형에는 Deployment, Job, Statefulset, Legacy를 선택 할 수 있는데 Statefulset 유형은 아직 배포 처리에서는 지원하지 않지만 저장은 가능하며, Deployment 유형은 온라인 애플리케이션, Job 유형은 배치 애플리케이션, Legacy 유형은 레거시 애플리케이션에 일치하는 유형이다.

배포 유형에는 아래 그림처럼 애플리케이션 스펙을 설정 시 선택하는 배포 리소스 유형과 일치하는 유형이다.

[그림 4.47] 애플리케이션에 배포 리소스 유형

[버전 정보] 탭 화면은 빌드팩이 실제로 어떤 동작이 이루어지는지에 대한 설정을 버전별로 관리하는 탭 화면이다. 즉 CI/CD 파이프라인 처리 과정에서 어떤 문제가 있을 때에는 이 탭 화면을 통해서 설정 정보를 확인해야 한다. 아래 그림이 버전 정보 탭 화면인데 이 빌드팩은 현재 3개의 버전이 저장되어 있다.

[그림 4.48] 빌드팩 조회/변경 - 버전 정보

위에 그림에서 3개의 버전으로 저장된 빌드팩 예시를 보여주는데 이 빌드팩 버전은 애플리케이션 수정(생성) 팝업 화면에서 아래 그림처럼 보여지고 선택할 수 있다. 다른 사용자를 위해서 빌드팩에 설명은 쉬운 말로 구체적으로 작성하는 것을 권장한다.

[그림 4.49] 온라인 애플리케이션 - 애플리케이션 수정(생성)

이런 빌드팩 버전 목록 화면에서 행이나 [추가] 버튼을 클릭하면 구체적인 설정을 하는 팝업을 열 수 있다. 아래 그림은 저장된 빌드팩의 버전 데이터이다.

[그림 4.50] 빌드팩 조회/변경 - 빌드팩 버전 조회/변경 - 기본 설정

빌드팩에서는 컨테이너 이미지를 빌드하기 위해서 도커파일의(Dockerfile) 내용을 설정할 수 있는 입력창을 제공하고 있다. 아래 그림에서는 이미 작성된 도커파일 설정이 보이는데 [추가] 버튼을 통해서 처음 만든다면, 텅빈 상태로 보여진다.

[그림 4.51] 빌드팩 조회/변경 - 빌드팩 버전 조회/변경 - 도커파일

$ docker pull python:3.7.7-slim

가급적이면 도커 파일의 내용은 다른 텍스트 에디터를 이용해 만들고 테스트를 미리 로컬환경이나 테스트를 할 수 있는 환경에서 완료하고 도커파일 탭 화면의 입력창에 내용을 입력한다. 만약 개발팀에서(혹은 개발자) 내용을 전달해준다면 그것을 이용하여 입력창에 붙여넣기 하면되고 Dockerfile에 대한 자세한 문법은 https://docs.docker.com/engine/reference/builder/ 링크를 참고해서 작성하길 권장한다.

아래 그림은 CI/CD 파이프라인 탭 화면인데 젠킨스 CI/CD 파이프라인을 정의하는 화면이다. 예시에서는 완성된 CI/CD 파이프라인 설정을 보여주고 있지만 신규로 작성 시 템플릿을 제공하고 있다. CI/CD 파이프라인 설정 입력창이 협소하기 때문에 화면을 확장하는 버튼을() 이용해서 사용한다.

[그림 4.52] 빌드팩 조회/변경 - 빌드팩 버전 조회/변경 - CI/CD 파이프라인

위에 언급처럼 템플릿을 제공한다고 했는데 그 젠킨스 CI/CD 파이프라인 템플릿은 아래와 같다. 여기에 작성된 내용은 https://www.jenkins.io/doc/book/pipeline/ 문서를 기준으로 작성이 되었고 자세한 내용은 해당 링크로 이동하여 찾아보길 권장하며 여기서는 주요 키워드나 문법을 간략히 설명한다.

// for Gitlab with online

pipeline {
    environment {                                                                                                      
        DOMAIN_ID = "${application.domain_id}"
        APP_ID = "${application.app_id}"
        WORKSPACE_ID = "${application.workspace_id}"
        BUILDPACKVERSION_UUID = "${buildpack.version.uuid}"
        SYSTEM_URL = "${bxcr.system.url}"
        BXCP_TOKEN = "${bxcr.system.auth.token}"
        EXECUTE = "./execute.sh"
    }
    parameters {                                                                                                       
        // [변경 불가]    
        // 소스를 받을 Gitlab에 필요한 변수
        string(name: 'COMMIT_ID', defaultValue: 'git commit id', description: 'Git Commit ID')
        string(name: 'SOURCE_ID', defaultValue: 'root', description: 'Gitlab ID')
        string(name: 'SOURCE_PW', defaultValue: 'password', description: 'Gitlab PW')
        string(name: 'PROTOCOL', defaultValue: 'https', description: 'Gitlab TLS')
        string(name: 'GIT_HOST_URL', defaultValue: 'gitlab.bxcp.lab', description: 'Gitlab Host URL')
        string(name: 'GIT_SUB_URL', defaultValue: '/bookinfo/ratings', description: 'Gitlab SUB URL')
        string(name: 'GIT_PORT', defaultValue: '8443', description: '8443')
        string(name: 'BRANCH', defaultValue: 'master', description: 'git branch name')

        // 포탈 사용에 필요한 변수
        string(name: 'HARBOR_URL', defaultValue: 'https://registry.bxcp.lab', description: 'Harbor URL')
        string(name: 'HARBOR_ID', defaultValue: 'admin', description: 'Harbor ID')
        string(name: 'HARBOR_PW', defaultValue: 'password', description: 'Harbor PW')        
        string(name: 'BUILD_DESC', defaultValue: 'application patch', description: 'build description')
        string(name: 'DEPLOY_RES_TYPE', defaultValue: 'GITLAB', description: 'build description')
        
    }

    agent none
    stages {                                                                                                           
        stage('# Initialization') {                                                                                    
            agent {
                docker {
                    image 'alpine/curl:latest'
                }
            }
            steps {
                cleanWs()
                script {currentBuild.displayName = "${BUILD_NUMBER}||${params.BUILD_DESC}||${params.COMMIT_ID}"}
                sh '''
                    set '\053'x
                    echo "curl -X GET ${SYSTEM_URL}/buildpack/get/buildpackversions/${BUILDPACKVERSION_UUID}/templates/download?type=SCRIPT -H accept: */* -H Authorization: Bearer <...> -o /tmp/tmp.sh"
                    curl -s -k -X GET "${SYSTEM_URL}/buildpack/get/buildpackversions/${BUILDPACKVERSION_UUID}/templates/download?type=SCRIPT" -H "accept: */*" -H "Authorization: Bearer ${BXCP_TOKEN}" -o /tmp/tmp.sh
                    tr -d '\015' < /tmp/tmp.sh > ${EXECUTE}
                    chmod 755 ${EXECUTE}
                    set '\055'x
                '''
            }
        }

        stage('# Git Clone') {                                                                                         
            agent {
                docker { image 'bitnami/git:latest' }
            }
            steps {
                sh "${EXECUTE} gitClone"
            }
        }

        stage('# Application Build') {                                                                                 
            agent {
                docker { image 'gradle:latest' }
            }
            steps {
                sh "${EXECUTE} appBuild"
            }
        }

        stage('# Application Test') {                                                                                  
            agent {
                docker { image 'bash:latest' }
            }
            steps {
                sh "${EXECUTE} appTest"
            }
        }

        stage('# Image Build & Push') {                                                                                
            agent {
                docker {
                    image 'bwginfra/bookinfo_base:latest'
                    args '-v /etc/hosts:/etc/hosts'
                }
            }
            steps {
                sh "${EXECUTE} imageDelivery"
            }
        }

        stage('# Application Delivery') {                                                                              
            agent {
                docker { image 'cfmanteiga/alpine-bash-curl-jq:latest' }
            }
            steps {
                sh "${EXECUTE} appDelivery"
            }
        }
    }

    post {                                                                                                             
        always { 
            echo '### on always!'
        }

        failure { 
            echo '### on failure!'
        }

        success { 
            echo '### on success!'
        }
    }
}

이러한 젠킨스 파이프라인 스크립트를 작성 시 사용자의 네트워크 환경이 외부 접근을 할 수 없을 때에는 BXCP ADM 환경을 구성 시 같이 설치된 젠킨스에서 파이프라인 스크립트 작성에 사용할 수 있는 도구가 있다. 아래 그림은 해당 도구를 사용하기 위한 이동 순서를 나열한 그림이다.

[그림 4.53] 순서 1. 젠킨스 홈 화면 - 새로운 Item

[그림 4.54] 순서 2. 젠킨스 Item 정보 입력

[그림 4.55] 순서 3. Pipeline Syntax

아래 그림은 파이프라인 스크립트 웹 도구의 첫 화면인데 표시된 메뉴의 경우에는 인터넷 사용이 허용된 환경에서만 이동할 수 있다.

[그림 4.56] 인터넷 사용이 가능할 때 이용 가능한 메뉴

아래 그림은 [Snippet Generator] 메뉴의 화면인데 여기서는 다양한 Step을 정의하고 싶을 때 관련 코드 조각을 생성해서 사용자에게 제공할 수 있다. 그림에서는 "offline"이라는 Stage 스탭의 코드 조각을 생성한 결과를 보여주고 있다.

[그림 4.57] Snippet Generator

아래 그림을 보면 Snippet Generator 화면에서 선택할 수 있는 Step의 목록을 볼 수 있다. 다양한 형태에 Step이 있기 때문에 Step 선택 콤보에서 간략하게 설명이 있다. 하지만 요약된 설명으로는 해당 Step이 어떤 역할로 동작을 하는지를 이해하기에는 한계가 있으니 https://www.jenkins.io/doc/pipeline/steps/ 링크에서 참고할 필요가 있다.

[그림 4.58] 선택할 수 있는 Step 목록

아래 그림은 [Declarative Directive Generator] 메뉴의 화면인데 젠킨스 파이프라인 스크립트의 지시자를 기준으로 코드 조각을 생성하여 사용자에게 제공하는 화면이다. 예시에서는 agent 지시자에서 도커 이미지를 사용하는 샘플 코드 조각을 만들어 보는 예시이다.

[그림 4.59] Declarative Directive Generator

위에서 설명한 CI/CD 파이프라인 스크립트는 아래 그림처럼 젠킨스 파이프라인 실행 결과에서 보이는 형태의 순서로 처리가 되는 템플릿이다.

[그림 4.60] 젠킨스 파이프라인 실행결과 화면

그리고 이런 CI/CD 파이프라인 처리 현황은 [빌드] > [빌드 상세] 팝업 화면에서도 열람할 수 있다.

[그림 4.61] [빌드] > [빌드 상세]

빌드팩 버전 조회/변경 화면에서는 아래 그림처럼 배포에 사용하는 쿠버네티스 Deployment 리소스의 스펙을 재정의할 수 있도록 템플릿을 수정하는 화면을 제공한다.

[그림 4.62] 빌드팩 조회/변경 - 빌드팩 버전 조회/변경 - 쿠버네티스 리소스

위에 그림에 기본값으로 보여주는 템플릿은 아래 그림처럼 데이터베이스에 정의된 기본값으로 사용을 하고 있다. 데이터베이스에 있는 정보의 수정은 지양하며 빌드팩에서 재정의 하는 형태를(버전을 새롭게 만들어서 재정의) 권장한다. 그리고 이 쿠버네티스 리소스에 사용된 템플릿 값은 Handlebars 템플릿 언어를 기준으로 만들어져 있다. 애플리케이션의 스펙과 템플릿에서 사용하는 변수 등이 정교하게 만들어져 있기 때문에 가급적 수정을 지양하며 템플릿에 대한 문법은 https://handlebarsjs.com/guide/expressions.html#expressions 링크를 참고한다.

[그림 4.63] 데이터베이스 - 쿠버네티스 리소스

빌드팩 버전 조회/변경 화면에서는 CI/CD 파이프라인 처리에 사용하는 쉘스크립트 설정하는 탭 화면을 제공한다. 이 화면에서는 쉘스크립트를 재정의 할 수 있는데 bash 쉘 기준으로 작성한다.

[그림 4.64] 빌드팩 조회/변경 - 빌드팩 버전 조회/변경 - 쉘스크립트

위 그림에 나오는 쉘스크립트는 CI/CD 파이프라인 탭 화면에서 설정하는 젠킨스 파이프라인 스크립트와 더불어 가장 중요한 설정 중에 하나이다. 아래 코드조각은 위에서 설명했던 CI/CD 파이프라인 스크립트의 코드 조각인데 쉘스크립트가 어디에서 쓰이는지 보여주는 예시이다. 아래에서 sh "${EXECUTE} appBuild" 스크립트로 작성된 부분에서 쉘스크립트를 사용한 부분이다.

stage('# Application Build') {
	agent {
		docker { image 'gradle:latest' }
	}
	steps {
		sh "${EXECUTE} appBuild"
	}
}			

위에 그림에 기본값으로 보여주는 쉘스크립트의 템플릿은 이전에 언급한 쿠버네티스 리소스와 같이 아래 그림처럼 데이터베이스에 정의된 기본값으로 사용하고 있다. 데이터베이스에 있는 정보의 수정은 지양하며 빌드팩에서 재정의 하는 형태를 권장한다.

[그림 4.65] 데이터베이스 - 쉘스크립트

헬름 관리 화면에서 이미 헬름 차트를 추가했다는 가정하에 시스템 컴포넌트에서 [컴포넌트 추가] 버튼을 클릭하면 신규 컴포넌트를 추가할 수 있다. 아래는 신규로 컴포넌트를 추가 시 열리는 팝업이다.

[그림 4.67] 헬름 리스트 선택 화면

위에 그림과 같이 헬름관리를 통해서 등록된 헬름차트 목록에서 1개를 선택하면 아래와 같이 SUMMARY, VALUES 탭에서 내용을 확인할 수 있다. VALUES는 헬름 차트에 설치 과정에서 사용하는 기본값을 보여주고 있다. 설치 버튼을 누르면 컴포넌트 추가를 하는 팝업으로 전환된다.

[그림 4.68] 헬름 리스트 선택 - SUMMARY

[그림 4.69] 헬름 리스트 선택 - VALUES

아래 그림은 위에서 설치 버튼을 누르면 전환되는 팝업 화면으로 헬름 차트를 설치하기 위한 정보를 직접 입력하는 화면이다.

[그림 4.70] 컴포넌트 추가 - 기본 설정

입력하는 항목마다 다음 의미를 가진다.

기본 설정 탭에서 정보를 입력하고 아래 그림과 같이 VALUES 탭으로 이동하면 헬름 차트에 정보를 추가로 설정할 수 있다.

[그림 4.71] 컴포넌트 추가 - VALUES

VALUES 탭에서 정보를 아래와 같이 수정할 수 있다. 예시에서는 간단하게 레이블 정보를 추가했다.

[그림 4.72] 컴포넌트 추가 - VALUES - 레이블 추가

그리고 새롭게 추가한 정보를 Diff 버튼을 눌러서 기본값과 비교할 수 있다. 아래 그림은 버튼을 누른 결과 팝업창이다.

[그림 4.73] 컴포넌트 추가 - VALUES - 레이블 추가 - Diff

비교를 하고 이상이 없으면 비교창을 닫고 설치 버튼을 누르면 해당 헬름 차트를 쿠버네티스 클러스터에 설치가 진행된다. 아래는 설치 버튼을 누른 직후에 시스템 컴포넌트 목록 화면이다.

[그림 4.74] 시스템 컴포넌트 화면 - Installing

일정 시간이 지나면 아래 그림과 같이 Phase는 Succeeded로 Status는 deployed로 변경된 것을 확인할 수 있다.

[그림 4.75] 시스템 컴포넌트 화면 - Succeeded

예시로 사용된 헬름 차트는 디플로이먼트 리소스로 쿠버네티스 환경에 설치를 하기 때문에 아래 그림처럼 [워크로드 리소스] > [디플로이먼트] 메뉴에서 실제로 처리된 리소스를 확인할 수 있다.

아래 그림에서 알 수 있듯이 컴포넌트 ID, VALUES 탭에서 추가한 레이블 정보가 설정된 것을 알 수 있다.

[그림 4.76] 워크로드 리소스 - 디플로이먼트 - 시스템 컴포넌트 확인

[그림 4.77] 워크로드 리소스 - 디플로이먼트 - 레이블 - 시스템 컴포넌트 확인

위에서 신규로 추가한 시스템 컴포넌트는 메뉴를 통해서 수정하거나 조회된 목록에 1개의 컴포넌트를 선택하면 아래와 같은 컴포넌트 조회/변경 팝업을 열 수 있다.

[그림 4.78] 컴포넌트 조회/변경

아래와 같이 설치한 컴포넌트에 추가로 레이블을 아래와 같이 입력을 했다.

[그림 4.79] 컴포넌트 조회/변경 - 레이블 추가

신규로 컴포넌트를 추가하는 과정과 동일하게 아래 그림처럼 Diff 버튼을 통해서 비교를 할 수 있다.

[그림 4.80] 컴포넌트 조회/변경 - Diff

비교 결과 창을 닫고 [업그레이드] 버튼을 누르면 업그레이드를 처리한다. 아래 그림을 보면 기대하는 결과와 다르게 오류가 발생한 것을 알 수 있다.

[그림 4.81] 시스템 컴포넌트 화면 - Failed

문제의 내용을 확인하기 위해 이벤트 리소스 화면으로 이동하고 내용을 훑어보면 HelmRelease 유형에 이벤트가 아래 그림과 같이 보인다. 내용을 보면 업그레이드 처리를 위해서는 비밀번호를 조회해서 설정해야 한다는 의미로 보인다.

[그림 4.82] 이벤트 리소스

이벤트 메세지에 나온 내용을 기준으로 아래와 같이 커맨드를 사용해서 비밀번호를 획득한다. 여기서는 시크릿 리소스에 지정된 비밀번호를 확인하는 과정에 kubectl 커맨드를 이용했지만 [컨피그 리소스] > [시크릿] 메뉴를 통해서 제공하는 쿠버네티스 시크릿 리소스를 더욱 간편하게 내용을 확인할 수 있다.

[그림 4.83] kubectl secret 리소스 조회

위에서 알아낸 비밀번호를 복사해서 아래 그림과 같이 팝업을 열고 VALUES 탭에서 비밀번호를 변경한다.

[그림 4.84] VALUES 비밀번호 입력

위에 그림에서 비밀번호를 채워 넣고 업그레이드를 하면 아래 그림처럼 더 이상 문제가 되는 값이 없기 때문에 Phase가 Upgrading 상태로 보인다. 일정 시간이 지나고 새로고침하면 Succeeded 상태로 변경된 것을 알 수 있다.

[그림 4.85] 시스템 컴포넌트 업그레이드 Phase - Upgrading

[그림 4.86] 시스템 컴포넌트 업그레이드 Phase - Succeeded

파드 목록에서 1개 행을 클릭하면 파드 리소스에 상세 정보를 열람할 수 있는 팝업이 열린다. 아래 그림은 Details 탭에 대한 화면이다. 파드 리소스 스펙에서 사용자가 참고해야 하는 주요 속성을 선정하여 표현하는 탭 화면이다.

[그림 4.97] 팝업 - Details - 상단

[그림 4.98] 팝업 - Details - 하단

애플리케이션의 스펙에서 Ingress 유형이 Service Mesh 유형으로 설정된 상태로 배포되면 아래 그림처럼 istio에서 설정하는 사이드카 컨테이너가 자동으로 주입되어서 배포된다.

[그림 4.99] Istio Sidecar

앞에서 언급한 Details 탭에서 볼 수 없는 정보를 YAML 탭에서 열람할 수 있다. 아래 그림은 파드 리소스 스펙을 yaml 포맷으로 제공하는 탭을 볼 수 있다. 이 화면에서는 단순히 yaml 포맷으로 열람만 하는 화면이 아니고 스펙의 수정, 다운로드, 새로고침 등에 기능을 제공하고 있다.

[그림 4.100] 팝업 - YAML

파드 리소스에는 컨테이너가 하나 이상 동작하고 있는데, Log 탭에서는 컨테이너에 대한 로그를 스트리밍 방식으로 열람할 수 있다.

아래는 쿠버네티스 환경에 로그를 열람하는 커맨드 예시이고, 그 밑에 그림은 샘플 파드 리소스에 대한 Log 탭 화면이다.

$ kubectl logs -f -n bookinfo ratings-23e76-76bd7499b8-w7f9b -c ratings

[그림 4.101] 팝업 - Log - 예시 1

2개 이상의 컨테이너가 있는 파드에 경우는 아래 그림처럼 로그를 열람하고 싶은 컨테이너를 선택하여 다른 로그를 볼 수 있다.

[그림 4.102] 팝업 - Log - 컨테이너 선택

$ kubectl logs -f -n bookinfo ratings-23e76-76bd7499b8-w7f9b -c istio-proxy

그리고 Log 탭에서는 로그 열람을 위해서 다양한 기능을 제공하고 있다.

[그림 4.103] 팝업 - Log - 예시 2

Events 탭에서는 해당 파드에 대한 이벤트만을 스트리밍 방식으로 열람할 수 있는 탭 화면이다. 아래 그림은 BXCP ADM에서 온라인 애플리케이션에 대한 파드 갯수를 +1 처리한 이후에 발생한 이벤트 예시를 보여주고 있다.

[그림 4.104] 팝업 - Events

아래는 터미널 환경에서 쿠버네티스 파드 컨테이너로 접속하는 커맨드 예시인데, 이런 기능을 제공하는게 Terminal 탭이다. 이 Terminal 탭 화면은 6.1.22절. “bxcr.common.terminal.allow” 값에 의해서 허용 여부를 조절할 수 있다. 터미널로 접속하는 목적은 주로 애플리케이션을 배포하기 위해서 초반에 리서치를(어떠한 환경변수를 사용할지, 환경변수를 어떻게 사용되는지, 어떤 디렉토리를 기준으로 애플리케이션 소스를 위치시킬지 등) 할 때나 배포된 이후에 애플리케이션의 문제에 대한 디버깅에 주로 사용된다.

[그림 4.105] kubectl 커맨드 사용 예시

Terminal 탭 화면진입 했을 때 보여지는 화면의 예시이다.

[그림 4.106] 팝업 - Terminal

아래 그림은 다양한 커맨드를 Terminal 탭에서 입력한 예시를 보여준다.

[그림 4.107] 팝업 - Terminal - 명령어 사용 예시

파드 팝업의 마지막 탭은 Metrics탭인데 파드 리소스 기준에 다양한 메트릭 정보를 사용자에게 제공하는 탭 화면이다. 아래 그림을 보면 CPU, MEMORY, NETWORK, WAITING REASON, TERMINATED REASON, RESTART 항목들에 대한 메트릭 정보를 제공하는 것을 알 수 있다.

[그림 4.108] 팝업 - Metrics

kubectl 커맨드를 사용해서 관련 내용을 조회할 수 있지만 메트릭 정보의 경우에는 UI를 통한 열람이 훨씬 직관적으로 내용을 파악할 수 있기 때문에 kubectl 커맨드를 사용하는 것보다는 UI를 통해 보는 것을 권장한다.

아래 그림 2개는 디플로이먼트 목록 화면에서 1개 리소스를 클릭하여 열리는 Details 탭 화면이다. 예시에 리소스는 BXCP ADM 온라인 애플리케이션으로 배포가 처리되었기 때문에 Name 항목에 해시값이 포함되어 있는 것을 알 수 있다.

디플로이먼트 리소스는 레플리카셋, 파드 리소스를 만들기 때문에 Details 탭에서는 파드 갯수를 조정하는 버튼이 배치된 것이 특징이다.

[그림 4.113] 팝업 - Details - 상단

[그림 4.114] 팝업 - Details - 하단

위 그림 예시의 쿠버네티스 디플로이먼트 리소스 스펙을 보면 kubefed.io/managed: true 레이블이 설정되어 있는데, 이것이 설정된 쿠버네티스 리소스는 스펙을 변경해도 그 변경 사항이 반영되지 않는다.

YAML 탭은 적용된 디플로이먼트 리소스의 스펙을 YAML 포맷으로 보여주는 탭 화면이다. 스펙을 수정하여 저장하거나 파일로 다운로드 하는 기능을 제공하고 있다.

[그림 4.115] 팝업 - YAML

Replica Sets 탭은 디플로이먼트 리소스가 생성 시키는 레플리카셋 리소스를 열람할 수 있는 탭 화면이다. 이 화면은 [워크로드 리소스] > [레플리카셋] 메뉴의 화면과 동일한 화면을 사용한다. 조회된 레플리카셋을 클릭하면 레플리카셋 팝업을 열어서 리소스의 상세 현황을 열람할 수 있다.

[그림 4.116] 팝업 - Replica Sets

레플리카셋 리소스는 파드를 관리하기 때문에 아래 그림처럼 파드 갯수를 조정하는 버튼을 제공하고 있는 것을 알 수 있다.

[그림 4.117] 팝업 - Replica Sets - 상세 - 상단

[그림 4.118] 팝업 - Replica Sets - 상세 - 하단

Pods 탭 화면은 디플로이먼트 리소스가 생성 시키는 파드 리소스를 열람하는 탭 화면이다. 이 화면은 위에서 설명했던 [워크로드 리소스] > [파드] 메뉴의 화면과 동일한 화면이다. 이 Pods 탭 화면도 위에 Replica Sets 탭 화면과 동일하게 조회된 파드를 클릭하면 파드 팝업을 열어서 리소스의 상세 현황을 열람할 수 있다.

[그림 4.119] 팝업 - Pods

Events 탭 화면은 디플로이먼트 리소스를 기준으로 발생하는 쿠버네티스 이벤트 리소스를 스트리밍 방식으로 보여주는 탭 화면이다. 아래 그림은 레플리카 갯수의 조정을 통해서 발생한 이벤트 리소스가 조회된 예시이다.

[그림 4.120] 팝업 - Events

Metrics 탭 화면은 디플로이먼트 리소스를 기준으로 메트릭 정보를 사용자에게 제공하는 탭 화면이다. 파드 리소스의 메트릭 탭 화면과 유사하지만 레플리카 갯수가 추가로 보이는 것이 다른 점이다.

[그림 4.121] 팝업 - Metrics

레플리카셋 목록 화면에서 1개 리소스를 클릭하면 상세 현황을 제공하는 팝업이 열리는데 아래 그림 2개 예시와 같다. 레플리카셋 리소스는 파드 리소스를 관리하는 소유자 성격이 특징이다. 그래서 아래 그림에 상단에는 파드 리소스 갯수를 조정하는 버튼이 제공되는 것을 알 수 있다.

[그림 4.125] 팝업 - Details - 상단

[그림 4.126] 팝업 - Details - 하단

앞에서 언급한 Details 탭에서 볼 수 없는 정보를 YAML 탭에서 열람할 수 있다. 아래 그림은 레플리카셋 리소스 스펙을 yaml 포맷으로 제공하는 탭을 볼 수 있다. 이 화면에서는 단순히 yaml 포맷으로 열람만 하는 화면이 아니고 스펙의 수정, 다운로드, 새로고침 등에 기능을 제공하고 있다.

[그림 4.127] 팝업 - YAML

Pods 탭 화면은 레플리카 리소스가 생성 시키는 파드 리소스를 열람하는 탭 화면이다. 이 화면은 위에서 설명했던 [워크로드 리소스] > [파드] 메뉴의 화면과 동일한 화면이다. 이 Pods 탭 화면도 조회된 파드를 클릭하면 파드 팝업을 열어서 리소스의 상세 현황을 열람할 수 있다.

[그림 4.128] 팝업 - Pods

Events 탭 화면은 레플리카셋 리소스를 기준으로 발생하는 쿠버네티스 이벤트 리소스를 스트리밍 방식으로 보여주는 탭 화면이다. 아래 그림은 레플리카 갯수의 조정을 통해서 발생한 이벤트 리소스가 조회된 예시이다.

[그림 4.129] 팝업 - Events

Metrics 탭 화면은 레플리카셋 리소스를 기준으로 메트릭 정보를 사용자에게 제공하는 탭 화면이다. 파드 리소스의 메트릭 탭 화면과 유사하지만 레플리카 갯수가 추가로 보이는 것이 다른 점이다.

[그림 4.130] 팝업 - Metrics

스테이트풀셋 목록 화면에서 1개 리소스를 클릭하면 상세 현황을 제공하는 팝업이 열리는데 아래 그림 2개 예시와 같다. 스테이트풀셋 리소스 또한 파드 리소스를 관리하는 소유자 성격이 특징이다. 그래서 아래 그림에 상단에는 파드 리소스 갯수를 조정하는 버튼이 제공되는 것을 알 수 있다.

[그림 4.134] 팝업 - Details - 상단

[그림 4.135] 팝업 - Details - 하단

앞에서 언급한 Details 탭에서 볼 수 없는 정보를 YAML 탭에서 열람할 수 있다. 아래 그림은 스테이트풀셋 리소스 스펙을 yaml 포맷으로 제공하는 탭을 볼 수 있다. 이 화면에서는 단순히 yaml 포맷으로 열람만 하는 화면이 아니고 스펙의 수정, 다운로드, 새로고침 등에 기능을 제공하고 있다.

[그림 4.136] 팝업 - YAML

Pods 탭 화면은 스테이트풀셋 리소스가 생성 시키는 파드 리소스를 열람하는 탭 화면이다. 이 화면은 위에서 설명했던 [워크로드 리소스] > [파드] 메뉴의 화면과 동일한 화면이다. 이 Pods 탭 화면도 조회된 파드를 클릭하면 파드 팝업을 열어서 리소스의 상세 현황을 열람할 수 있다.

[그림 4.137] 팝업 - Pods

아래 그림 2개를 기준으로 스테이트풀셋 리소스에 의해서 만들어진 파드 리소스에 이름을 보면 기존에 봤던 형태와는 다르게 비교적 읽기 쉬운 형태로 생성된 것을 알 수 있다. 앞에서 언급했듯이 안정된 고유한 네트워크 식별자, 순차적 정상 배포(graceful deployment)와 스케일링 등의 적합성에 알맞다는 의미에 부합한다.

[그림 4.138] 팝업 - Pods - bxcp-ela-elasticsearch-master-0

[그림 4.139] 팝업 - Pods - bxcp-ela-elasticsearch-master-1

Events 탭 화면은 스테이트풀셋 리소스를 기준으로 발생하는 쿠버네티스 이벤트 리소스를 스트리밍 방식으로 보여주는 탭 화면이다. 아래 그림은 레플리카 갯수의 조정을 통해서 발생한 이벤트 리소스가 조회된 예시이다.

[그림 4.140] 팝업 - Events

Metrics 탭 화면은 스테이트풀셋 리소스를 기준으로 메트릭 정보를 사용자에게 제공하는 탭 화면이다.

[그림 4.141] 팝업 - Metrics

데몬셋 목록 화면에서 1개 리소스를 클릭하면 상세 현황을 제공하는 팝업이 열리는데 아래 그림 2개 예시와 같다. 데몬셋 리소스는 노드 당 1개 파드가 스케줄 되는 특성이 있기 때문에 앞에서 살펴봤던 디플로이먼트나 스테이트풀셋 리소스와는 다르게 파드 갯수 조정을 할 수 없다.

[그림 4.145] 팝업 - Details - 상단

[그림 4.146] 팝업 - Details - 하단

앞에서 언급한 Details 탭에서 볼 수 없는 정보를 YAML 탭에서 열람할 수 있다. 아래 그림은 데몬셋 리소스 스펙을 yaml 포맷으로 제공하는 탭을 볼 수 있다. 이 화면에서는 단순히 yaml 포맷으로 열람만 하는 화면이 아니고 스펙의 수정, 다운로드, 새로고침 등에 기능을 제공하고 있다.

[그림 4.147] 팝업 - YAML

Pods 탭 화면은 데몬셋 리소스가 생성 시키는 파드 리소스를 열람하는 탭 화면이다. 이 화면은 위에서 설명했던 [워크로드 리소스] > [파드] 메뉴의 화면과 동일한 화면이다. 이 Pods 탭 화면도 조회된 파드를 클릭하면 파드 팝업을 열어서 리소스의 상세 현황을 열람할 수 있다.

[그림 4.148] 팝업 - Pods

Events 탭 화면은 데몬셋 리소스를 기준으로 발생하는 쿠버네티스 이벤트 리소스를 스트리밍 방식으로 보여주는 탭 화면이다. 아래 그림은 샘플 데몬셋 리소스를 restart 커맨드를 사용하여 발생한 이벤트 리소스가 조회된 예시이다.

$ kubectl rollout restart ds -n bookinfo example

[그림 4.149] 팝업 - Events

Metrics 탭 화면은 데몬셋 리소스를 기준으로 메트릭 정보를 사용자에게 제공하는 탭 화면이다.

[그림 4.150] 팝업 - Metrics

아래 그림은 잡 리소스 스펙을 yaml 포맷으로 제공하는 탭을 볼 수 있다. 이 화면에서는 단순히 yaml 포맷으로 열람만 하는 화면이 아니고 스펙의 수정, 다운로드, 새로고침 등에 기능을 제공하고 있다.

[그림 4.154] 팝업 - YAML

Pods 탭 화면은 잡 리소스가 생성 시키는 파드 리소스를 열람하는 탭 화면이다. 이 화면은 위에서 설명했던 [워크로드 리소스] > [파드] 메뉴의 화면과 동일한 화면이다. 이 Pods 탭 화면도 조회된 파드를 클릭하면 파드 팝업을 열어서 리소스의 상세 현황을 열람할 수 있다.

[그림 4.155] 팝업 - Pods

Events 탭 화면은 잡 리소스를 기준으로 발생하는 쿠버네티스 이벤트 리소스를 스트리밍 방식으로 보여주는 탭 화면이다. 아래 그림은 샘플 잡 리소스를 생성하자마자 발생한 이벤트 리소스가 조회된 예시이다.

[그림 4.156] 팝업 - Events

서비스 목록 화면에서 1개 리소스를 클릭하면 상세 현황을 제공하는 팝업이 열리는데 아래 그림과 같다. 서비스 리소스의 핵심 역할은 보통 파드 리소스에 요청을 열결하기 위한 서비스 디스커버리 역할을 하기 때문에 상세 현황의 내용을 보면 그에 대한 정보를 볼 수 있다.

[그림 4.161] 팝업 - Details

위에 그림을 기준으로 보면 서비스에 접근하는 포트는 9080으로 접근이 필요하고 이 포트 번호로 외부에서 트래픽이 유입되면 20.0.192.19 혹은 20.0.192.47 주소에 9080 포트번호의 파드로 트래픽이 전달되는 형태가 된다.

아래 그림은 서비스 리소스 스펙을 yaml 포맷으로 제공하는 탭을 볼 수 있다. 이 화면에서는 단순히 yaml 포맷으로 열람만 하는 화면이 아니고 스펙의 수정, 다운로드, 새로고침 등에 기능을 제공하고 있다.

이미 서비스를 제공하고 있는 쿠버네티스 서비스 리소스의 스펙을 수정하는 행위는 각별히 유의해서 처리한다.

[그림 4.162] 팝업 - YAML

Pods 탭 화면은 서비스 리소스가 받은 트래픽을 전달하기 위한 파드 리소스를 열람하는 탭 화면이다. 이 화면은 위에서 설명했던 [워크로드 리소스] > [파드] 메뉴의 화면과 동일한 화면이다. 이 Pods 탭 화면도 조회된 파드를 클릭하면 파드 팝업을 열어서 리소스의 상세 현황을 열람할 수 있다.

[그림 4.163] 팝업 - Pods

Events 탭 화면은 서비스 리소스 기준의 이벤트 리소스를 조회하는 화면이다. 하지만 서비스 리소스의 이벤트가 발생한 적이 없기 때문에 그림 예시는 없다.

스토리지 클래스 목록 화면에서 1개 리소스를 클릭하면 상세 현황을 제공하는 팝업이 열리는데 아래 그림과 같다. 스토리지 클래스 리소스는 지정한 프로비즈너를 기준으로 동적인 스토리지 할당이 되기 때문에 프로비즈너 속성과 볼륨을 바인딩 하는 유형 속성이 눈여겨 볼 내용이다.

[그림 4.167] 팝업 - Details

아래 그림은 스토리지 클래스 리소스 스펙을 yaml 포맷으로 제공하는 탭을 볼 수 있다. 이 화면에서는 단순히 yaml 포맷으로 열람만 하는 화면이 아니고 스펙의 수정, 다운로드, 새로고침 등에 기능을 제공하고 있다.

[그림 4.168] 팝업 - YAML

퍼시스턴트 볼륨 목록 화면에서 1개 리소스를 클릭하면 상세 현황을 제공하는 팝업이 열리는데 아래 그림과 같다. 퍼시스턴트 볼륨 리소스는 용량이 제한된 상태로 파드에서 이용이 가능하지만 리소스에 특성상 클러스터 전체 장애를 일으킬 가능성이 있는 민감한 리소스이다.

[그림 4.173] 팝업 - Details

아래 그림은 퍼시스턴트 볼륨 리소스 스펙을 yaml 포맷으로 제공하는 탭을 볼 수 있다. 이 화면에서는 단순히 yaml 포맷으로 열람만 하는 화면이 아니고 스펙의 수정, 다운로드, 새로고침 등에 기능을 제공하고 있다.

[그림 4.174] 팝업 - YAML

위에 그림을 기준으로 스펙을 살펴보면 다음과 같다.

apiVersion: v1
kind: PersistentVolume
metadata:
  finalizers:
    - kubernetes.io/pv-protection                                                                                      
  labels:
    bankwareglobal.io/storage: bwg-temp-vol
  name: bwg-temp-vol-0
  resourceVersion: '37008512'
spec:
  accessModes:
    - ReadWriteOnce                                                                                                    
  capacity:
    storage: 10Gi                                                                                                      
  claimRef:
    apiVersion: v1
    kind: PersistentVolumeClaim
    name: volume-claim-example-0                                                                                       
    namespace: bookinfo                                                                                                
    resourceVersion: '37000312'
    uid: f1959dea-fae0-4178-a0dd-caefb92d1187
  hostPath:
    path: /tmp/bwg_temp_vol                                                                                            
    type: ''
  persistentVolumeReclaimPolicy: Delete                                                                                
  storageClassName: manual                                                                                             
  volumeMode: Filesystem                                                                                               
status:
  phase: Bound

퍼시스턴트 볼륨 클레임 목록 화면에서 1개 리소스를 클릭하면 상세 현황을 제공하는 팝업이 열리는데 아래 그림과 같다. 퍼시스턴트 볼륨 리소스와 유사한 속성들로 구성된 것을 알 수 있다.

[그림 4.178] 팝업 - Details

아래 그림은 퍼시스턴트 볼륨 클레임 리소스 스펙을 yaml 포맷으로 제공하는 탭을 볼 수 있다. 이 화면에서는 단순히 yaml 포맷으로 열람만 하는 화면이 아니고 스펙의 수정, 다운로드, 새로고침 등에 기능을 제공하고 있다.

[그림 4.179] 팝업 - YAML

YAML 탭 화면은 일관되게 수정, 다운로드, 새로고침 기능을 제공하지만 퍼시스턴트 볼륨 클레임 리소스가 Bound 상태로 변경되고 이 리소스의 수정하여 저장하면 오류가 발생하게 된다. 아래 그림은 스토리지 용량을 변경하고 싶은 어떠한 사용자가 1Gi에서 5Gi 사이즈로 변경후 [Save] 버튼을 눌러 오류가 발생한 예시를 보여준다.

[그림 4.180] 팝업 - YAML - 오류

컨피그맵 목록 화면에서 1개 리소스를 클릭하면 상세 현황을 제공하는 팝업이 열리는데 아래 그림은 파일명을 키로 정하고 값을 선언한 컨피그맵 리소스에 상세 현황이다.

[그림 4.184] 팝업 - Details - 파일명 키

그리고 아래 그림은 일반적인 키-값 데이터와 파일명-파일내용 데이터 2개를 선언한 예시를 보여준다.

[그림 4.185] 팝업 - Details - 파일명 키, 키-값

아래 그림은 컨피그맵 리소스 스펙을 yaml 포맷으로 제공하는 탭을 볼 수 있다. 이 화면에서는 단순히 yaml 포맷으로 열람만 하는 화면이 아니고 스펙의 수정, 다운로드, 새로고침 등에 기능을 제공하고 있다.

[그림 4.186] 팝업 - YAML

시크릿 목록 화면에서 1개 리소스를 클릭하면 상세 현황을 제공하는 팝업이 열리는데 아래 그림은 일반적으로 사용하는 Opaque 타입에 시크릿 리소스에 상세 현황이다.

[그림 4.191] 팝업 - Details - 예시 1

가급적 BXCP ADM에서 제공하는 화면을 사용해서 시크릿 리소스를 열람하는 것을 권장한다. 그 이유는 시크릿 리소스는 기본적으로 base64 인코딩이 처리된 상태로 사용자에게 데이터를 보여주고 있기 때문이다. 위에 그림에 시크릿 리소스는 kubectl 커맨드를 사용하여 확인하려면 다음과 같은 과정을 거쳐야 데이터를 열람할 수 있다.

$ kubectl get secret -n bookinfo pythonapp
NAME        TYPE     DATA   AGE
pythonapp   Opaque   2      149d

$ kubectl get secret -n bookinfo pythonapp -o yaml
apiVersion: v1
data:
  password: YndnMTIzJFY=
  username: YndndXNlcg==
kind: Secret
metadata:
  creationTimestamp: "2022-11-15T01:03:02Z"
  name: pythonapp
  namespace: bookinfo
  resourceVersion: "2146461"
  uid: a5faa86f-e9af-4d08-bceb-71214686e758
type: Opaque

$ echo 'YndndXNlcg==' | base64 -d
bwguser%
			

그리고 아래 그림은 인증서 파일과 토큰 등을 저장한 시크릿 리소스 상세 현황 예시이다.

[그림 4.192] 팝업 - Details - 예시 2

아래 그림은 시크릿 리소스 스펙을 yaml 포맷으로 제공하는 탭을 볼 수 있다. 이 화면에서는 단순히 yaml 포맷으로 열람만 하는 화면이 아니고 스펙의 수정, 다운로드, 새로고침 등에 기능을 제공하고 있다.

[그림 4.193] 팝업 - YAML

노드 목록 화면에서 1개 리소스를 클릭하면 상세 현황을 제공하는 팝업이 열리는데 아래 그림이 노드 상세 현황이다.

Details - 상단 탭 화면은 주로 노드가 배치된 머신에 정보를 표시하고 있는데 네트워크 주소 정보, OS 정보 등이 있다.

[그림 4.196] 팝업 - Details - 상단

Details - 하단 탭 화면은 노드의 컨디션과 노드에 저장된 컨테이너 이미지 목록을 볼 수 있다. 노드 컨디션은 관리자가 확인할 중요한 정보인데 다음을 참고한다.

[그림 4.197] 팝업 - Details - 하단

그리고 위에 그림에 Images 항목에 나오는 정보는 이 노드에 캐시된 컨테이너 이미지에 목록 정보이다. 워크로드 리소스에 스펙에서 이미지를 가져오는 정책을 결정하는 imagePullPolicy 속성과도 연관이 있다. IfNotPresent 정책을 사용한 리소스가 이 노드에 스케줄링 될 때에 컨테이너 이미지 정보를 노드에 캐시된 이미지 정보를 찾아보게 된다.

아래 그림은 노드 리소스 스펙을 yaml 포맷으로 제공하는 탭을 볼 수 있다. 이 화면에서는 단순히 yaml 포맷으로 열람만 하는 화면이 아니고 스펙의 수정, 다운로드, 새로고침 등에 기능을 제공하고 있다. 하지만 노드 리소스를 수정, 삭제하는 처리는 매우 위험한 상황으로 전개될 수 있으므로 신중하게 처리한다. 참고로 kubectl drain 명령어도 고려할 것을 권고한다.

[그림 4.198] 팝업 - YAML

Pods 탭 화면은 노드 리소스에서 스케줄된 파드 리소스를 열람하는 탭 화면이다. 이 화면은 이전에 설명했던 [워크로드 리소스] > [파드] 메뉴의 화면과 동일한 화면이며 조회된 파드를 클릭하면 파드 팝업을 열어서 리소스의 상세 현황을 열람할 수 있다.

[그림 4.199] 팝업 - Pods

Metrics 탭 화면은 노드 리소스를 기준으로 메트릭 정보를 사용자에게 제공하는 탭 화면이다.

[그림 4.200] 팝업 - Metrics

네임스페이스 목록 화면에서 1개 리소스를 클릭하면 상세 현황을 제공하는 팝업이 열리는데 아래 그림이 네임스페이스 상세 현황이다.

[그림 4.204] 팝업 - Details

네임스페이스 리소스의 스펙은 내용이 없기 때문에 상세 현황에서 특별한 항목은 없지만 예시 그림에서 눈여겨 볼만한 것은 레이블이다. BXCP ADM은 Istio와 kubefed를 사용하고 있는데 레이블 정보에 보면 그것을 사용하기 위한 설정이 된 것을 알 수 있다.

아래 그림은 네임스페이스 리소스 스펙을 yaml 포맷으로 제공하는 탭을 볼 수 있다. 이 화면에서는 단순히 yaml 포맷으로 열람만 하는 화면이 아니고 스펙의 수정, 다운로드, 새로고침 등에 기능을 제공하고 있다.

[그림 4.205] 팝업 - YAML

Metrics 탭 화면은 네임스페이스 리소스를 기준으로 메트릭 정보를 사용자에게 제공하는 탭 화면이다.

[그림 4.206] 팝업 - Metrics

이벤트 리소스 메뉴를 통해서 화면으로 이동하면 기본 선택된 클러스터를 기준으로 발생하는 이벤트가 바로 조회가 된다. 아래 그림이 이벤트 리소스 메뉴에 화면이고, 따로 상세 화면이나 팝업은 제공되지 않는다.

[그림 4.208] 이벤트 리소스

이 화면에서 제공하는 정보는 kubectl 커맨드를 이용하여 쿠버네티스 이벤트 리소스를 조회하는 것과 유사하지만 스트리밍 방식을 사용하기 때문에 더욱 편의성이 높다. 아래는 kubectl 커맨드를 사용한 이벤트 리소스를 확인하는 예시이다.

$ kubectl get event -n kube-federation-system
LAST SEEN   TYPE      REASON                          OBJECT                  MESSAGE
2m12s       Warning   RetrievingClusterHealthFailed   kubefedcluster/member   Failed to retrieve health of the cluster: Get "https://tf-k8s-lb-member-host-20cf168afc237f56.elb.ap-northeast-2.amazonaws.com:6443/healthz?timeout=3s": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
17m         Warning   RetrievingClusterHealthFailed   kubefedcluster/member   Failed to retrieve health of the cluster: Get "https://tf-k8s-lb-member-host-20cf168afc237f56.elb.ap-northeast-2.amazonaws.com:6443/healthz?timeout=3s": context deadline exceeded
22m         Warning   RetrievingClusterHealthFailed   kubefedcluster/member   Failed to retrieve health of the cluster: Get "https://tf-k8s-lb-member-host-20cf168afc237f56.elb.ap-northeast-2.amazonaws.com:6443/healthz?timeout=3s": dial tcp 43.200.121.14:6443: i/o timeout
			

이벤트 리소스는 클러스터별로 제공되기 때문에 다른 클러스터에 이벤트 리소스를 열람하기 위해서는 아래 그림과 같이 클러스터 정보를 변경하는 콤보 박스를 통해서 처리할 수 있다.

[그림 4.209] 이벤트 리소스 - 클러스터 필터

클러스터에서 발생하는 모든 이벤트를 스트리밍으로 보여주는 화면이기 때문에 불필요한 정보를 보기 싫다면 키워드를 사용해서 필터링 할 수 있다. 필터링 가능한 항목은 Kind, Namespace, Name, Message, Type 총 5가지가 있다.

[그림 4.210] 이벤트 리소스 - 키워드 필터

아래 그림은 Kind 항목에 ReplicaSet 키워드를 필터링한 결과를 나타낸다.

[그림 4.211] 이벤트 리소스 - 키워드(Kind) 필터 - ReplicaSet

이벤트 리소스 화면에 진입하면 자동으로 스트리밍이 활성화 상태로 보여지기 때문에 이벤트가 많으면 너무 빨리 넘어가거나 발생한 이벤트에 메세지를 복사할 경우가 발생할 때 불편할수 있다. 그래서 버튼을 통해서 스트리밍 상태를 제어할 수 있다. 아래는 버튼을 통해서 일시 정지한 예시이다.

[그림 4.212] 이벤트 스트리밍 일시 정지

위에서 언급한 팝업은 아래 그림과 같은 형태로 제공이 된다.

[그림 4.213] 모니터링 선택 팝업

모니터링 선택 팝업에서는 클러스터, 상태 정보를 표시하고 있고 서비스 추적, 로그, 서비스 메쉬 3개 솔루션을 선택할 수 있다.

서비스 추적을 클릭하면 분산 서비스간 트랜잭션을 추적하는 오프소스인 Jaeger에서 제공하는 화면을 새 탭으로 열어준다.

[그림 4.214] 서비스 추적(Jaeger)

로그를 클릭하면 쿠버네티스 환경에서 발생하는 로그 데이터를 시각화하기 위한 오픈소스인 Kibana 화면을 새 탭으로 열어준다.

[그림 4.215] 로그(Kibana)

서비스 메쉬를 클릭하면 Istio 에서 제공하는 Kiali 화면을 새 탭으로 열어준다.

[그림 4.216] 로그(Kibana)

아래 그림은 감사 로그 목록에서 1개 로그를 클릭 시 열리는 팝업 화면이다. 화면에 표기되는 정보는 BXCP ADM에서 제공하는 API 사용시 발생하는 정보를 제공한다. 목록에서 보여주는 항목과 추가로 요청 URL 항목을 보여주고 있다.

[그림 4.219] 팝업 - 기본 설정

아래는 로그 메시지 탭 화면으로 이동한 그림인데 여기서는 리소스 및 액션을 기준으로 응답 데이터를 보여주는 화면이다.

[그림 4.220] 팝업 - 로그 메시지

아래 그림은 에러 로그 목록에서 1개 로그를 클릭 시 열리는 팝업 화면이다. 화면에 표기되는 정보는 BXCP ADM에서 제공하는 API 사용시 발생하는 에러 로그 정보를 제공한다. 목록에서 보여주는 항목과 추가로 요청 URL 항목을 보여주고 있다.

[그림 4.223] 팝업 - 기본 설정

아래는 로그 메시지 탭 화면으로 이동한 그림인데 여기서는 리소스 및 액션을 기준으로 요청 데이터와 응답 데이터를 보여주는 화면이다.

[그림 4.224] 팝업 - 로그 메시지

아래 그림은 헬름 관리 목록 화면에서 1개의 헬름 차트 정보를 클릭 시 열리는 팝업 화면이다. 상세 현황에서도 버전별로 목록 형태로 정보를 제공하고 있다. 각각의 버전별로 삭제를 할 수 있는 것이 특징이다.

[그림 4.235] 헬름버전 목록

아래 그림은 헬름 상세 화면에서 조회된 버전별 목록에서 1개의 버전 정보를 클릭 시 열리는 팝업 화면이다. 추가한 헬름에 선택한 버전의 구체적인 SUMMARY 정보를 보여주고 있으며, 이 상세 화면에서는 따로 수정하거나 삭제하는 기능은 없고 정보 열람만 가능하다.

[그림 4.236] 헬름버전 - SUMMARY

아래 그림은 헬름 상세 화면에서 조회된 버전별 목록에서 1개의 버전 정보를 클릭 시 열리는 팝업에 VALUES 탭 화면이다. 추가한 헬름에 선택한 버전의 구체적인 VALUES 정보를 보여주고 있으며, 이 상세 화면 또한 수정하거나 삭제하는 기능은 없고 정보 열람만 가능하다.

[그림 4.237] 헬름버전 - VALUES

토큰 목록에서 1개 행을 클릭하면 토큰 상세 정보를 열람할 수 있는 팝업이 열린다. 아래 그림은 생성된 토큰에 대한 상세 정보를 제공하는 팝업 화면이다.

[그림 4.243] 팝업 - 상단(Webhook)

토큰 타입이 웹훅(Webhook)이기 때문에 [구성관리] > [토큰 관리] 메뉴를 통해서 만들어진 토큰이 아닌 것을 알 수 있다. 프로젝트 ID, 애플리케이션 ID 정보가 각각 설정이 되어있으며, 그 밑에는 Access Token 정보도 제공된다. 즉 이 토큰은 Gitlab과 Jenkins간 웹훅 처리에 이용하는 토큰이다.

[그림 4.244] 팝업 - 하단(Webhook)

아래 그림은 관리자 계정으로(sysadmin) BXCP ADM 로그인 처리를 성공 시 만들어지는 토큰의 예시이다. 그렇기 때문에 토큰 타입이 로그인 사용자로 표시가 되는 것을 알 수 있다.

[그림 4.245] 팝업 - 상단(Webhook)

아래 그림에 등록 일시와 위 그림에 만료 일시 정보를 보면 로그인을 통해서 만들어진 토큰의 유효 시간은 60분인 것을 알 수 있다.

[그림 4.246] 팝업 - 하단(Webhook)

조회된 인증 정보 목록에서 1개를 클릭하면 설정된 값을 변경할 수 있는 팝업 화면이 열린다. 아래 그림은 Gitlab 리소스 유형의 인증 정보인데 bookinfo 프로젝트를 범위로 인증에 사용하는 정보인 것을 알 수 있다.

[그림 4.253] 인증 상세

조회된 메뉴 목록에서 상위 메뉴 데이터 1개를 클릭하면 메뉴의 상세 정보를 열람할 수 있는 팝업 화면이 열린다. 아래 그림은 상위 메뉴에 대한 상세 화면 팝업이다.

[그림 4.281] 인증 상세

(Developer) [온라인 애플리케이션] 메뉴를 통해서 온라인 애플리케이션 목록 화면으로 이동을 하면 다음에 그림과 같이 애플리케이션에 대한 요약 정보를 상세화면으로 진입하지 않아도 열람할 수 있다.

[그림 4.304] BXCP 온라인 애플리케이션 목록

아래 그림처럼 카드 형태로 1개의 온라인 애플리케이션에 현황을 나타내고, 다음에 항목으로 애플리케이션에 정보를 표현한다.

[그림 4.305] BXCP 온라인 애플리케이션

온라인 애플리케이션 정보를 수정하거나 삭제하고 싶다면 다음 그림처럼 메뉴를 클릭해서 처리할 수 있다.

[그림 4.307] BXCP 온라인 애플리케이션 현황 메뉴

애플리케이션 삭제 메뉴를 클릭한다면 다음과 같이 사용자에 확인을 받고 삭제가 처리된다.

[그림 4.308] BXCP 온라인 애플리케이션 삭제 확인

온라인 애플리케이션 목록을 보여주는 화면에서 [Create Application] 버튼을 클릭하면 1개의 온라인 애플리케이션을 생성할 수 있는 팝업 열거나, 카드 형태 영역에서 오른쪽 위에 메뉴를() 클릭하여 애플리케이션 수정 메뉴를 누를 때도 동일한 팝업을 볼 수 있다.

[그림 4.309] 온라인 애플리케이션 생성(수정) - 기본 설정

참고

애플리케이션 ID 정보를 입력하고 [검증] 버튼을 눌러서 검증이 완료되어야 다음으로 진행할 수 있다. 단, 이러한 처리는 애플리케이션을 처음 생성할 때 거치는 단계이며, 수정 시 애플리케이션 ID는 고칠 수 없으므로 거쳐가는 단계가 아니다.

[그림 4.310] BXCP 온라인 애플리케이션 검증완료

위에 그림을 기준으로 언급이 필요한 항목을 다음에 설명한다.

4.36.4.2 배포 리소스

온라인 애플리케이션을 배포할 때 사용될 온라인 애플리케이션에 대한 코드, 이미지, 바이너리 등을 지정할 수 있는데, 선택할 수 있는 유형은 아래 그림을 참고한다.

[그림 4.311] 선택할 수 있는 배포 리소스 유형

유형 - Gitlab

배포할 리소스가 Gitlab 서버에 관리되는 레파지토리인 경우에 사용하는 유형이다.

배포를 처리할 기준 브랜치를 지정해야 하며 미지정시 master 브랜치를 기준으로 처리된다. 이 Gitlab 유형은 빌드팩을 사용해서 배포가 이루어진다.

유형 - Container Image

배포할 리소스가 컨테이너 이미지 형태로 dockerhub, harbor 등에 레파지토리 서버를 사용하는 유형이다.

유형 - Object Storage

배포할 리소스가 http 프로토콜을 통해서 가져 올 수 있는 형태이면 사용하는 유형이다.

유형 - FTP

배포할 리소스가 ftp 프로토콜을 통해서 가져 올 수 있는 형태이면 사용하는 유형이다.

유형 - PCMS

배포 처리 자체를 다른 곳에서 이루어지는 형태에서 사용하는 유형이다.

인증선택

각각에 유형에 따라서 배포 리소스 접근 시 인증이 필요하면 선택하는 인증정보에 목록이다. 같은 프로젝트를 공유하는 다른 사용자가 필요한 인증을 이미 만들었다면 아래 그림과 같이 선택이 가능한데 알맞은 인증을 선택하여 사용가능하다.

[그림 4.312] 저장된 인증정보 선택 화면

직접 입력

미리 생성된 인증정보가 없거나 필요한 인증정보가 없을 때에는 사용자가 직접 입력을 통해서 인증 정보를 만들 수 있다.

인증유형은 Token, ID/PASSWORD, Certificate 3가지 형태로 저장이 가능하다.

4.36.4.3 빌드팩

온라인 애플리케이션을 배포할 때 다양한 처리 과정에서 사용되는 빌드팩을 선택해야 한다. 이 빌드팩은 PCMS 배포 리소스 유형을 제외한 다른 배포 리소스 유형은 모두 선택하게 되어있다.

[그림 4.313] 빌드팩 선택

[그림 4.314] 빌드팩 버전 선택

온라인 애플리케이션 생성(수정) - POD & CONTAINER 설정 탭에서는 쿠버네티스 서비스, 파드 리소스에 대한 설정을 할 수 있는 탭이다.

[그림 4.315] 온라인 애플리케이션 생성(수정) - POD & CONTAINER 설정

4.36.5.2 Service Type

배포 처리 시 만들어지는 서비스 스펙에 지정되는 Service Type 유형을 지정할 수 있다.

[그림 4.316] Service Type

4.36.5.4 Command

Dockerfile에 실행 명령어가 CMD로 정의된 경우, Command를 통해서 실행 명령어를 재정의 할 수 있습니다. 아래 그림과 같이 사용할 수 있다.

[그림 4.317] Command

4.36.5.5 Args

Dockerfile에 정의된 실행 명령어가 다음에 아규먼트를 지정하고자 할 때 Args 속성을 추가하여 주입할 수 있다. 아래 그림은 CMD, Args 같이 사용한 예시이다.

[그림 4.318] Args

4.36.5.6 Environment Variables

컨테이너에서 사용할 수 있는 환경변수를 지정할 수 있다. 환경변수를 일반적인 키-값 형태가 될수 있고 접근할 수 있는 컨피그맵이나 시크릿을 환경변수로 사용할 수 있다.

[그림 4.319] 일반 환경변수

[그림 4.320] 컨피그맵 환경변수

[그림 4.321] 시크릿 환경변수

4.36.5.7 Labels

사용자가 원하는 레이블을 설정할 수 있다. 이 레이블은 파드 리소스의 레이블로 설정된다.

[그림 4.322] 레이블 설정

4.36.5.8 Volumes

컨테이너가 사용할 볼륨을 정의하고, 그 볼륨을 컨테이너에 마운트 하는 설정을 할 수 있다.

[그림 4.323] Host Path 예시

위에 Host Path 그림 예시를 기준으로 실제 생성되는 파드 스펙은 아래와 같다. 편의상 다른 부분을 생략했다.

spec:
containers:
- volumeMounts:
	- mountPath: /etc/localtime
		name: tz-seoul
volumes:
- hostPath:
		path: /usr/share/zoneinfo/Asia/Seoul
		type: ""
	name: tz-seoul

그리고 아래는 Host Path 유형 이외에 선택할 수 있는 유형을 보여준다.

[그림 4.324] 볼륨 타입

4.36.5.9 Service Account

파드 스펙에서 사용하는 서비스 어카운트를 지정할 수 있다. 이 서비스 어카운트는 인증/인가 처리에 이용된다.

[그림 4.325] Host Path 예시

4.36.5.10 Node Selector

노드 셀렉터를 설정하면 파드가 스케줄 되는 시점에 원하는 노드에 배치를 유도 할 수 있다. 노드 리소스에 레이블 정보를 기반하므로 설정하기 전에 노드에 레이블 정보를 알아야 한다.

[그림 4.326] 노드 셀렉터 설정

4.36.5.11 Resource Quota

파드 스펙에 어느 정도에 컴퓨팅 파워를 사용할지 결정하는 Resource Quota를 설정할 수 있다.

[그림 4.327] Resource Quota 설정

경고

신중하게 설정하지 않으면 이 설정으로 인해서 장애가 발생할 수 있다.

온라인 애플리케이션이 속한 프로젝트에 정보를 프로젝트 정보 조회 버튼을 통해서 프로젝트 전체에 Resource Quota 정보를 확인하고 설정할 수 있다.

[그림 4.328] 프로젝트 정보 조회 버튼 사용

온라인 애플리케이션 생성(수정) - 롤아웃 탭에서는 온라인 애플리케이션을 쿠버네티스 클러스터에 배치하는 방법에 대한 설정을 할 수 있다.

4.36.6.1 Rolling

Rolling 롤아웃은 쿠버네티스 디플로이먼트에 롤오버 기능을 사용하는 유형으로 가용한 파드를 중단없이 교체하는 방식이다.

[그림 4.329] Rolling 롤아웃

[표 4.1] Rolling 롤아웃 속성

속성	값
Max Unavailable	롤링 업데이트 처리 중에 삭제할 수 있는 파드에 최대 갯수 혹은 최대 비중이다. 값을 높게 설정하면 롤링 업데이트 처리 시간을 줄일 수 있는 장점이 있지만 남아있는 파드에 트래픽이 집중되는 단점이 있다.
Max Surge	롤링 업데이트 처리를 시작할 때 생성할 수 있는 새로운 버전에 파드 최대 갯수 혹은 최대 비중이다. Max Unavailable 속성과 동일하게 높은 값을 설정하면 롤링 업데이트 처리 시간을 줄일 수 있지만, 클러스터 컴퓨팅 자원을 많이 사용하게 되는 단점이 있다.

4.36.6.2 Canary

Canary 롤아웃은 Istio에 기능을 사용하는 방법인데, 1개 온라인 애플리케이션에 BLUE 및 GREEN 버전의 애플리케이션을 모두 배포하고 트래픽에 대한 비중을 설정하여 서비스를 제공하는 배포 방식이다.

[그림 4.330] Canary 롤아웃

4.36.6.3 BLUE/GREEN

BLUE/GREEN(줄여서 BG) 롤아웃 또한 Istio에 기능을 사용하는 방법인데, Canary 유형과 비슷하게 1개 온라인 애플리케이션에 BLUE 및 GREEN 버전의 애플리케이션을 모두 배포하고 특정 조건을 만족하면 GREEN 버전으로 트래픽을 라우트하는 배포 방식이다. 여기서 특정 조건은 Request Matching 설정에 일치할 때를 의미한다.

Request Matching - Header 유형은 온라인 애플리케이션에 요청되는 http 헤더 정보에서 조건에 만족하면 GREEN 버전 애플리케이션으로 트래픽이 라우트되는 유형이다.

[그림 4.331] BG - header

Request Matching - Query Param 유형은 온라인 애플리케이션에 요청되는 http 쿼리 파라미터 정보가 조건에 만족하면 GREEN 버전 애플리케이션으로 트래픽이 라우트되는 유형이다.

[그림 4.332] BG - query

INGRESS 설정 탭은 온라인 애플리케이션에 접근하는 트래픽이 외부/내부에서(North/South) 접근하는지 내부에서만(East/West) 접근하는지를 결정하는 유형의 선택과 그와 관련된 부가정보를 설정할 수 있다.

4.36.7.1 INGRESS 설정

[그림 4.333] INGRESS 설정

• 트래픽 유형

  North/South는 외부 호출을 위한 Service Mesh를 설정하고, East/West는 내부 호출을 위한 Service Mesh를 설정할 수 있다. 그리고 기본 설정에 Ingress 유형에 따라서 스펙이 달라진다.

• Request Matching(North/South)

  외부 요청을 수신하는 Istio ingress-gateway나 NGINX ingress-controller에서 온라인 애플리케이션으로 트래픽을 라우트 시 식별 정보로 사용한다. Uri나 Domain Name 유형으로 정의할 수 있다.

• Gateways(North/South)

  외부 요청을 수신하는 Gateway를 지정하며, Ingress 유형이 k8s Ingress로 선택 시 nginx gateway가 고정값이다.

• Expose Port

  컨테이너 이미지가 2개 이상의 포트로 동작할 때 트래픽을 보내줄 포트번호를 지정해야 한다.

4.36.7.2 INGRESS 설정 - Service Mesh 설정

Service Mesh 설정은 기본 설정 - Ingress 유형을 Service Mesh로 선택 시 보이는 설정 영역이다. Istio가 제공하는 기능을 설정하는 영역으로 이해하면 된다. Service Mesh 설정의 경우에는 장애포인트로 역효과가 나타날수 있기 때문에 신중하게 설정해야 한다.

[그림 4.334] Service Mesh 설정

• Request Timeouts

  Envoy 프록시가 지정된 서비스의 응답 받아야 하는 최대 대기시간을 설정할 수 있다. 설정하지 않으면 비활성화 상태로 작동하지 않습니다.

• Retries

  초기 호출이 실패할 경우 Envoy 프록시가 서비스에 연결을 시도하는 최대 횟수를 의미하는 설정이다. 재시도 횟수, 재시도 처리에 타임아웃을 지정할 수 있고 에러 유형을 지정할 수도 있다.

• Fault Injection

  Istio를 사용한 네트워크 설정이 완료된 상태에서(혹은 테스트 목적으로) Istio에 Fault Injection 기능으로 오류를 주입할 수 있다.

  경고

  Retries, Request Timeouts 설정과 Fault Injection 설정을 같이 사용할 수 없다.

• Load Balancer

  특정한 대상에 적용할 부하분산 정책을 지정할 수 있다.

• Circuit Breakers

  목적지로 트래픽을 라우트 처리 시 지정한 조건에 따라서 일정 시간 동안 로드밸런스 풀에서 제외하도록 설정할 수 있다.

쿠버네티스 파드 스펙에 설정할 수 있는 Readiness, Liveness, Startup Probe를 설정할 수 있다.

HEALTH CHECK 설정을 따로 입력하지 않으면 아래와 같은 형태로 보여진다.

[그림 4.335] HEALTH CHECK 설정

그리고 아래는 Readiness Probe 버튼을 눌러서 Readiness Probe 설정을 입력한 예시를 볼 수 있다.

[그림 4.336] Readiness Probe

위에 그림과 같은 설정이 디플로이먼트 리소스로 배포되면 아래와 같은 형태로 만들어진다. 일부 속성값은 기본값이 처리된 것을 알 수 있다.

spec:
template:
	spec:
		containers:
		- readinessProbe:
				failureThreshold: 3
				httpGet:
					path: /bookinfo/productpage/health
					port: 9080
					scheme: HTTP
				periodSeconds: 10
				successThreshold: 1
				timeoutSeconds: 1
			

온라인 애플리케이션을 배치할 클러스터를 지정할 수 있다. 그리고 특정 클러스터에만 별로도 지정할 속성을 오버라이드 처리할 수 있다.

아래는 호스트 역할에 클러스터만 선택한 예시를 보여주고 있다.

[그림 4.337] 가용 클러스터 설정

가용 클러스터 설정 탭에서는 선택한 클러스터에만 따로 스펙을 오버라이드 하는 기능이 있다. 아래 그림에 나온 예시는 디플로이먼트 스펙을 기준으로 오버라이드 할 수 있는 항목을 보여주고 있다.

[그림 4.338] 가용 클러스터 설정 - Overrides

위에서 언급한 레플리카셋 개수를 설정할 수 있지만 [가용 클러스터 설정] 탭 화면에서도 재정의 할 수 있다. spec.replicas 항목을 선택하고 5로 지정을 한다면 BXCP ADM에서 배포 시 아래와 같이 FederatedDeployment 리소스의 스펙이 만들어진다.

spec:
  overrides:
  - clusterName: host
    clusterOverrides:
    - op: replace
      path: /spec/replicas
      value: 5
			

온라인 애플리케이션 목록에서 애플리케이션 카드를 1개 클릭하면 진입할 수 있는 상세 정보를 제공하는 화면이다.

[그림 4.339] 온라인 애플리케이션 상세 화면

위 그림은 배포가 성공적으로 이루어진 상태에서 온라인 애플리케이션 상세 화면을 나타냈다. 상세 화면은 최대한 많은 정보를 사용자에게 보여주기 위해 개발되었으므로 다음과 같은 정보를 제공한다.

4.36.10.1 애플리케이션

애플리케이션 현황은 온라인 애플리케이션 목록에서 보여지는 정보와 동일한 정보를 사용자에게 알려주는 부분이다.

[그림 4.340] 온라인 애플리케이션 상세 - 애플리케이션

Rolling 롤아웃인 경우에는 수정 및 삭제 처리를 할 수 있는 메뉴를 제공한다.

[그림 4.341] 온라인 애플리케이션 상세 - 애플리케이션 - 메뉴

4.36.10.2 클러스터

클러스터 현황은 클러스터를 기준으로 몇 개에 온라인 애플리케이션 파드가 구동하고 있는지 표현하며, 레플리카 갯수를 조정하는 기능을 제공한다.

[그림 4.342] BLUE 버전만 배포된 상태에 클러스터 현황

그리고 롤아웃이 CANARY 또는 BG 일때 두 번째 배포가 이루어지면 다음 그림과 같이 BLUE, GREEN 버전이 배포된 상태를 알 수 있다.

[그림 4.343] BLUE / GREEN 버전 모두 배포된 상태에 클러스터 현황

클러스터 현황을 보면 레플리카셋 개수를 늘리는() 버튼이나, 줄이는() 버튼이 있는데 이것을 사용하면 클러스터별, 버전별 리플리카 갯수를 조정할 수 있다. 아래는 BLUE 버전 애플리케이션에 리플리카 갯수를 버튼을 통해서 +1 처리한 예시를 보여준다.

[그림 4.344] 리플리카 1개 상태를 증가시키는 버튼을 클릭한 이후 확인 메시지

4.36.10.3 메트릭

메트릭 현황은 클러스터 현황에서 선택한 파드에 대한 다양한 메트릭 정보를 제공한다.

[그림 4.345] 온라인 애플리케이션 상세 - 메트릭

4.36.10.4 파드

파드 현황은 선택한 클러스터를 기준으로 애플리케이션에 파드 목록을 열람할 수 있다. 주요 상태를 나타내는 정보가 포함된 것이 특징이다.

[그림 4.346] 온라인 애플리케이션 상세 - 파드

주요한 상태 정보 이외에 파드 1개를 클릭하게 되면 자세한 파드 정보를 확인할 수 있다.

[그림 4.347] 온라인 애플리케이션 상세 - 파드 - 상세

4.36.10.5 서비스

온라인 애플리케이션의 배포가 완료되면 자동으로 생성되는 서비스에 현황을 나타내는 부분이다.

[그림 4.348] 온라인 애플리케이션 상세 - 서비스

위에서 언급한 파드 현황에서 상세 정보를 확인할 수 있는것과 동일하게 쿠버네티스 서비스 리소스에 자세한 정보를 확인할 수 있다.

[그림 4.349] 온라인 애플리케이션 상세 - 서비스 - 상세

4.36.10.6 컨피그맵

온라인 애플리케이션 스펙에서 컨피그맵 리소스를 지정했다면 그에 대한 컨피그맵 현황을 확인할 수 있다.

[그림 4.350] 온라인 애플리케이션 상세 - 컨피그맵

아래는 컨피그맵 리소스에 상세한 내용을 확인한 예시이다.

[그림 4.351] 온라인 애플리케이션 상세 - 컨피그맵 - 상세

4.36.10.7 시크릿

온라인 애플리케이션 스펙에서 시크릿 리소스를 지정했다면 그것에 대한 시크릿 리소스 현황을 확인할 수 있다.

[그림 4.352] 온라인 애플리케이션 상세 - 시크릿

아래는 시크릿에 상세 내용을 확인한 예시이다.

[그림 4.353] 온라인 애플리케이션 상세 - 시크릿 - 상세

4.36.10.8 퍼시스턴트 볼륨 클레임

온라인 애플리케이션 스펙에서 퍼시스턴트 볼륨 클레임 리소스를 지정했다면 그것에 대한 퍼시스턴트 볼륨 클레임 현황을 확인할 수 있다.

[그림 4.354] 온라인 애플리케이션 상세 - 퍼시스턴트 볼륨 클레임

[그림 4.355] 온라인 애플리케이션 상세 - 퍼시스턴트 볼륨 클레임 - 상세

4.36.10.9 상태

온라인 애플리케이션 스펙을 기준으로 배포가 이루어지면 다양한 리소스가 생성이 되는데, 상태를 보여주는 현황을 다음과 같이 볼수 있다. kubectl describe 커맨드에서 보여주는 정보와 비슷한 내용으로 이해하면 된다.

[그림 4.356] 온라인 애플리케이션 상세 - 상태

확인하고 싶은 상태가 있다면 아래 그림처럼 우측 상단에 필터 메뉴를 클릭해서 원하는 상태를 필터링할 수 있다.

[그림 4.357] 온라인 애플리케이션 상세 - 상태 - 필터 메뉴

4.36.10.10 이벤트

온라인 애플리케이션 배포로 생성된 쿠버네티스 리소스에 관련된 이벤트 정보를 다음과 같이 확인할 수 있다.

[그림 4.358] 온라인 애플리케이션 상세 - 이벤트

참고

쿠버네티스 이벤트 리소스의 경우에는 영구히 저장되지 않기 때문에 일정 시간이 지나면 이벤트 리소스 현황에 조회 결과가 없어진다.

위에서 짧게 언급한 롤아웃에 따라서 애플리케이션 상세 화면이 어떤 내용을 보여주는지 설명한다.

본 설명에서는 ROLLING 롤아웃은 해당하지 않으며 CANARY, BLUE/GREEN(줄여서 BG) 롤아웃 일 때만 해당한다.

[그림 4.359] 온라인 애플리케이션 GREEN 버전 배포

위 그림은 BLUE 버전 온라인 애플리케이션이 배포된 이후에 GREEN 버전에 애플리케이션이 추가로 배포된 상태를 보여주고 있다. 클러스터 현황 부분에서 색상으로 버전을 구분하고 작동하고 있는 파드 갯수를 나타낸다.

애플리케이션 현황에 빌드 항목에는 11 버전은 BLUE 버전, 12 버전은 GREEN 버전에 대한 정보를 제공하고 있다.

파드 현황을 보면 파드의 이름 왼쪽에 색상으로 구분되는 아이콘을 통해서 식별을 용이하게 한다.

아래 그림을 보면 GREEN 버전에 온라인 애플리케이션 배포 시 상태를 각각 Type 항목 왼쪽에 색상으로 구분되는 아이콘이 위치해 있다.

[그림 4.360] 온라인 애플리케이션 GREEN 버전 배포 - 상태

위에서 BLUE, GREEN 버전 배포를 모두한 상태에서는 온라인 애플리케이션 상세 화면에서 이 상태에 대한 추가적인 처리를 할 수 있다.

[그림 4.361] 온라인 애플리케이션 롤아웃 처리 메뉴

BLUE, GREEN 버전이 모두 배포된 상태에서는 추가로 배포 처리가 이루어지지 않으며, 이 상태에서는 버전을 선택하는 처리를 완료해야만 배포를 다시 할 수 있다. 다음은 메뉴에 대한 설명이다.