Kubernetes - kubectl 활용팁

kubectl 활용 팁

Kubernetes 관련 정보들을 검색하던 중에 kubectl 툴을 좀 더 활용할 수 있는 팁 정보가 있어서 정리해 놓는다.

kubectl 은 쿠버네티스를 운영하기 위한 CLI 도구로 상당히 많은 기능들을 제공하기 때문에 기능들을 다 파악하는 것은 어렵지만 강력한 도구로 활용이 가능하다.

기본적인 사용법에 관련된 것은 Cheatsheet 를 참고하면 된다.

¶kubectl with Shell Completion

kubectl 은 bash 및 zsh가 내장된 쉘 완성 기능을 제공하기 때문에 명령, 플래그 및 객체를 네임스페이스 또는 파드 이름과 같이 자동 완성으로 사용하는 것이 훨씬 쉽다.

아래의 그림은 실제 자동완성 기능을 제공하도록 설정한 후의 사용법을 보여주는 것이다.

원문 에는 kubectl 바이너리 설치부터 설명이 되어 있지만 대부분은 kubernetes 설치환경일 것이므로 자동 완성만 처리하면 된다.

Notes

자동 완성 스크립트는 kubectl에 의해서 생성되므로 프로파일에 설정해서 사용하면 된다. 관련된 정보는 kubectl completion -h 를 확인하면 된다.

¶On linux, usnig bash

리눅스 bash 환경에서 자동완성 스크립트를 Shell 로 로드 처리는 아래의 명령을 사용하면 된다.

$ source <(kubectl completion bash)

프로파일에 적용하려면 아래의 명령으로 프로파일에 적용해 주면 된다.

$ echo "source <(kubectl completion bash)" >> ~/.bashrc

¶On MacOS, using bash

맥에서 bash 자동 완성을 수행하려면 아래의 명령으로 자동완성 지원 기능을 먼저 설치해야 한다.

$ brew install bash-completion

Shell에 자동완성 스크립트 로드 처리는 아래의 명령을 사용하면 된다.

$ source $(brew --prefix)/etc/bash_completion
$ source <(source <(kubectl completion bash)

프로파일에 적용하려면 아래의 명령으로 프로파일에 적용해 주면 된다.

$ echo "source $(brew --prefix)/etc/bash_completion" >> ~/.bash_profile
$ echo "source <(kubectl completion bash)" >> ~/.bash_profile

Kubernetes 구성 병합

여러 쿠버네티스 클러스들과 상호 작용을 하는 경우라면 쿠버네티스 설정을 병합하는 것이 일반적인 패턴이며 병하해서 사용할 떄 특정 클러스터를 사용하도록 하는 파라미터들을 서술하기 위해 context 개념을 사용한다.

제대로 운영하기에는 복잡하기 때문에 KUBECONFIG 환경 변수를 사용해서 구성 파일을 지정하도록 병합할 수 있다.

만일 병합할 2개의 쿠버네티스 클러스터 (cluster1, cluster2) 가 있다면 각 클러스터별로 정보를 가지는 설정 파일이 다음과 같을 것이므로 이를 개별 파일로 구성하도록 한다.

클러스터 #1 설정

$ kubectl config view --minify > cluster1-config
apiVersion: v1
clusters:
- cluster:
certificate-authority: cluster1_ca.crt
server: https://cluster1
name: cluster1
contexts:
- context:
cluster: cluster1
user: cluster1
name: cluster1
current-context: cluster1
kind: Config
preferences: {}
users:
- name: cluster1
user:
client-certificate: cluster1_apiserver.crt
client-key: cluster1_apiserver.key

클러스터 #2 설정 (#1 에서와 같이 처리해서 사용할 장소에 복사하면 된다)

$ cat cluster2-config
apiVersion: v1
clusters:
- cluster:
certificate-authority: cluster2_ca.crt
server: https://cluster2
name: cluster2
contexts:
- context:
cluster: cluster2
user: cluster2
name: cluster2
current-context: cluster2
kind: Config
preferences: {}
users:
- name: cluster2
user:
client-certificate: cluster2_apiserver.crt
client-key: cluster2_apiserver.key

위의 2개 설정을 KUBECONFIG 환경 변수를 통해서 접근할 수 있도록 병합하고 context 지정을 통해서 2개의 클러스터를 동적으로 사용할 수 있다. context 는 클러스터를 인증 및 상호작용하도록 구성을 참조할 수 있는 클러스터, 사용자 및 이름을 설명하는 맴 정보라고 생각하면 된다.

이제 --kubeconfig 플래그를 이용해서 각 파일의 context 정보를 확인할 수 있다.

$ kubectl --kubeconfig=cluster1-config config get-contexts
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
* cluster1 cluster1 cluster1
$ kubectl --kubeconfig=cluster2-config config get-contexts
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
* cluster2 cluster2 cluster2

각각의 설정 파일은 하나의 context를 가지기 때문에 서로 충돌하지 않으며, 두 파일을 실제 병합하면 두 개의 Context 가 모두 표시된다.

병합을 위해서 cluster-merge 라는 새로운 파일을 만들고 아래와 같이 처리를 하면 된다.

$ export KUBECONFIG=cluster-merge:cluster-config:cluster2-config
$ kubectl config get-contexts
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
* cluster1 cluster1 cluster1
cluster2 cluster2 cluster2

병합되는 순서는 지정된 순서대로 처리되고 current-context 는 첫번째 구성 파일에서 지정한 context 가 되기 떄문에 액티브 표시 (*) 가 cluster1 context 를 가르키고 있는 것을 확인할 수 있다.

context 를 2번쨰로 변경하면 정보를 아래와 같이 보여지게 된다.

$ kubectl config get-contexts
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
* cluster1 cluster1 cluster1
cluster2 cluster2 cluster2

$ kubectl config use-context cluster2
Switched to context "cluster2".

$ kubectl config get-contexts
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
cluster1 cluster1 cluster1
* cluster2 cluster2 cluster2

병합에 사용했던 파일을 확인해 보면 아래와 같이 변경된 것을 확인할 수 있다.

$ cat cluster-merge
apiVersion: v1
clusters: []
contexts: []
current-context: cluster2
kind: Config
preferences: {}
users: []

실제 사용되는 클러스터는 항상 current-context 정보로 확인할 수 있다.

Context는 강력하고 다양한 방법으로 활용 및 병합이 가능하다. 예를 들어 모든 kubectl 명령에 적용될 수 있도록 네임 스페이스를 지정하는 Context 를 만들 수도 있다. (사실 매번 네임스페이스 지정하는 것도 귀찮은 일이다)

$ kubectl config set-context cluster1_kube-system --cluster=cluster1 --namespace=kube-system --user=cluster1
Context "cluster1_kube-system" set.

$ cat cluster-merge
apiVersion: v1
clusters: []
contexts:
- context:
cluster: cluster1
namespace: kube-system
user: cluster1
name: cluster1_kube-system
current-context: cluster2
kind: Config
preferences: {}
users: []

위의 예는 cluster1 에 kube-system 이라는 네임스페이스를 모든 명령에 사용할 수 있도록 context를 구성한 것으로 아래와 같이 context를 지정해서 사용할 수 있다.

$ kubectl config use-context cluster_kube-system
Switched to context "cluster1_kube-system".

$ kubectl get pods
NAME READY STATUS RESTARTS AGE
default-http-backend-fwx3g 1/1 Running 0 28m
kube-addon-manager-cluster 1/1 Running 0 28m
kube-dns-268032401-snq3h 3/3 Running 0 28m
kubernetes-dashboard-b0thj 1/1 Running 0 28m
nginx-ingress-controller-b15xz 1/1 Running 0 28m

context 에 네임스페이스가 지정되어 있기 때문에 각 명령 단위로 추가로 지정할 필요가 없다.

¶Kubernetes API 에 대한 정보 확인

Kubernetes는 API 정보 제공을 위해서 swagger UI 가 통합되어 있다. 따라서 아래의 명령으로 json 문서를 얻을 수도 있다.

$ kubectl proxy
$ curl -O 127.0.0.1:8001/swagger.json

아니면 직접 http://localhost:8001/api/ 페이지를 통해 정보를 확인할 수도 있다.

만일 json 문서를 활용한다면 jq 툴을 이용해서 활용할 수도 있다.

$ cat swagger.json | jq '.paths | keys[]'
"/api/"
"/api/v1/"
"/api/v1/configmaps"
"/api/v1/endpoints"
"/api/v1/events"
"/api/v1/namespaces"
"/api/v1/nodes"
"/api/v1/persistentvolumeclaims"
"/api/v1/persistentvolumes"
"/api/v1/pods"
"/api/v1/podtemplates"
"/api/v1/replicationcontrollers"
"/api/v1/resourcequotas"
"/api/v1/secrets"
"/api/v1/serviceaccounts"
"/api/v1/services"
"/apis/"
"/apis/apps/"
"/apis/apps/v1beta1/"
"/apis/apps/v1beta1/statefulsets"
"/apis/autoscaling/"
"/apis/batch/"
"/apis/certificates.k8s.io/"
"/apis/extensions/"
"/apis/extensions/v1beta1/"
"/apis/extensions/v1beta1/daemonsets"
"/apis/extensions/v1beta1/deployments"
"/apis/extensions/v1beta1/horizontalpodautoscalers"
"/apis/extensions/v1beta1/ingresses"
"/apis/extensions/v1beta1/jobs"
"/apis/extensions/v1beta1/networkpolicies"
"/apis/extensions/v1beta1/replicasets"
"/apis/extensions/v1beta1/thirdpartyresources"
"/apis/policy/"
"/apis/policy/v1beta1/poddisruptionbudgets"
"/apis/rbac.authorization.k8s.io/"
"/apis/storage.k8s.io/"
"/logs/"
"/version/"

¶기타 명령

api-versions 명령은 관리자로 실행되며, RBAC가 활성화된 경우라면 다른 API 세트 정보가 표시될 수 있다.

$ kubectl api-versions
apps/v1beta1
authentication.k8s.io/v1beta1
authorization.k8s.io/v1beta1
autoscaling/v1
batch/v1
batch/v2alpha1
certificates.k8s.io/v1alpha1
coreos.com/v1
etcd.coreos.com/v1beta1
extensions/v1beta1
oidc.coreos.com/v1
policy/v1beta1
rbac.authorization.k8s.io/v1alpha1
storage.k8s.io/v1beta1
v1

explain 명령은 각 파트에 대한 이해를 위한 기능적인 도움을 제공한다.

$ kubectl explain
You must specify the type of resource to explain. Valid resource types include:
* all
* certificatesigningrequests (aka 'csr')
* clusters (valid only for federation apiservers)
* clusterrolebindings
* clusterroles
* componentstatuses (aka 'cs')
* configmaps (aka 'cm')
* daemonsets (aka 'ds')
* deployments (aka 'deploy')
* endpoints (aka 'ep')
* events (aka 'ev')
* horizontalpodautoscalers (aka 'hpa')
* ingresses (aka 'ing')
* jobs
* limitranges (aka 'limits')
* namespaces (aka 'ns')
* networkpolicies
* nodes (aka 'no')
* persistentvolumeclaims (aka 'pvc')
* persistentvolumes (aka 'pv')
* pods (aka 'po')
* poddisruptionbudgets (aka 'pdb')
* podsecuritypolicies (aka 'psp')
* podtemplates
* replicasets (aka 'rs')
* replicationcontrollers (aka 'rc')
* resourcequotas (aka 'quota')
* rolebindings
* roles
* secrets
* serviceaccounts (aka 'sa')
* services (aka 'svc')
* statefulsets
* storageclasses
* thirdpartyresources
error: Required resource not specified.
See 'kubectl explain -h' for help and examples.

예를 들어 explain deploy 명령을 실행해 보고, deploy 의 좀더 세분화된 객체를 지정해서 정보를 확인할 수도 있다.

$ kubectl explain deploy.spec.template.spec.containers.livenessProbe.exec
RESOURCE: exec <Object>
DESCRIPTION:
One and only one of the following should be specified. Exec specifies the
action to take.
ExecAction describes a "run in container" action.
FIELDS:
command <[]string>
Command is the command line to execute inside the container, the working
directory for the command is root ('/') in the container's filesystem. The
command is simply exec'd, it is not run inside a shell, so traditional shell
instructions ('|', etc) won't work. To use a shell, you need to explicitly
call out to that shell. Exit status of 0 is treated as live/healthy and
non-zero is unhealthy.

¶Conclusion

다양한 기능들을 제공하기 때문에 모든 것을 알지도 못하고 정리하는 것도 쉽지는 않지만 다양한 자료들을 확인하면서 유용하다고 생각되는 기능들은 비록 발 번역 수준에 오타, 다른 이해가 있더라도 정리를 해 나갈 예정이다.

현재는 프로젝트를 쉬고 있는 중이지만, 향후 실제 기업에서 운영되는 어플리케이션들을 Containerize 처리와 Kubernetes Cluster에 배포 운영하는 프로젝트를 진행할 예정이기 때문에 좀 더 현실적이고 구체적인 사례들을 정리할 수 있을 것 같다.

---

References

• https://coreos.com/blog/kubectl-tips-and-tricks
• https://kubernetes.io/docs/tasks/tools/install-kubectl/