메인 콘텐츠로 건너뛰기

5가지 Kubernetes 쉘 요령

5ShellTricks_BlogImages_Blog_1920x1008

안녕하세요! 저는 Linode 개발자 앤드류입니다. 저는 관리형 Kubernetes 솔루션을 구축하는 과정에서 Kubernetes로 일상적 작업을 더 간편하게 만드는 데 사용할 수 있는 몇 가지 요령을 발견하고 생성했습니다. 저는 이 5가지 요령을 여러분과 공유하고 싶었고 여러분도 저만큼 유용하게 사용하시길 바랍니다.

1. 메타 쉘 요령

저는 올해 KubeCon Europe에서 CKA 준비에 대한 Olive Power의 강연을 통해 이 요령을 처음 보았습니다.

kubectl <command> --help | grep kubectl

모든 kubectl 명령어는 도움말 출력에서 여러 예시를 포함하고 있으며, 이것은 그러한 예시를 한 번에 모두 확인하는 빠른 방법입니다. 이 예시는 문서를 읽는 것만으로 확실하지 않을 수 있는 유용한 방법으로, 매개변수와 플래그를 결합하는 방법에 대한 아이디어를 제공할 수 있습니다.

현재 kubectl run 명령어는 가장 많은 수의 예시를 렌더링합니다. 18. 그러나 내가 가장 자주 사용하는 명령어는 kubectl get입니다. 그 예시 중 하나를 살펴보겠습니다.

kubectl get pod test-pod -o custom-columns=CONTAINER:.spec.containers[0].name,IMAGE:.spec.containers[0].image

이 명령어는 kubectl get 출력을 변환하여 포드에 배포된 컨테이너 버전만 제공합니다. 약간의 변경으로 출력을 훨씬 더 유용하게 만들 수 있습니다. 첫 번째 컨테이너(containers [0])의 이름과 이미지만 요청한다는 점에 주목하세요. kubectl에서 지원하는 JSONPath 구문을 사용하면 모든 포드에 포함된 모든 컨테이너의 모든 버전을 나열할 수 있습니다.

kubectl get pod -o custom-columns=CONTAINER:.spec.containers[*].name,IMAGE:.spec.containers[*].image -A

이 요령을 사용하면 클러스터에서 카나리아 이미지 또는 버전 차이를 찾기 위해 개별 포드 리소스를 탐색하지 않아도 됩니다. kgi 별칭(및 네임스페이스 선택기 -A 제거됨)을 사용하여 클러스터에서 실행 중인 kube-apiserver의 버전을 찾을 수 있습니다. 아래를 참조하세요.

$ kgi -n kube-system -l component=component=kube-apiserver
CONTAINER        IMAGE
kube-apiserver   k8s.gcr.io/kube-apiserver:v1.14.5
kube-apiserver   k8s.gcr.io/kube-apiserver:v1.14.5
kube-apiserver   k8s.gcr.io/kube-apiserver:v1.14.5

다음 명령어는 모든 기본 예시의 최신 목록을 표시합니다. 전에 본 적 없는 플래그를 선택해 실험해 보세요!

for c in $(kubectl --help | egrep "^\s+([a-z-]+)" -o); do echo -e "$(kubectl $c --help | egrep '^\s+kubectl')"; done

2. 네임스페이스 하나당 메모리 사용량 확인

우리 중 일부는 awk가 awk { 인쇄 $ 1 }보다 훨씬 더 많다는 것을 알고 있습니다. 최근에, 나는 더 깊이 파고 유닉스 역사의 타이탄의일부에서 우리에게 온이 믿을 수 없을만큼 강력한 언어의 기초를 배웠습니다. 다음은 한 라이너로 별칭할 만큼 짧기 때문에 매우 유용한 awk 프로그램의 예입니다. 각 네임스페이스의 모든 포드에서 사용하는 MiB 메모리 수를 합산하고 인쇄하고 클러스터에 긴 네임스페이스 이름이 포함된 경우에도 깨끗한 출력을 위해 awk의 인쇄물을 사용합니다. kubectl 출력의 집계 보기가 필요한 경우 awk를 사용하는 것이 좋습니다.

kubectl top pod -A --no-headers=true | awk '{a[$1] += $4} END {for (c in a) printf "%-35s %s\n", c, a[c]}'

3. 일반 텍스트로 시크릿 보기

시크릿에 의존하는 앱을 개발할 경우 kubectl 출력을 base64로 파이프 처리하는 방법을 찾는 것이 번거로울 수 있습니다. 이를 디코딩하기 위해 쉘 파이프라인이나 작은 스크립트를 작성하셨을 수 있겠죠. 저는 여러 줄 출력을 지원하지 않거나, 줄 바꿈을 추가하거나 삭제하거나, 필드 이름의 컨텍스트가 사라지는 것 등의 여러 단점이 있는 몇 가지 다른 옵션을 보았습니다. Ashley Schuett의 kubectl용 시크릿 디코딩 플러그인을 사용하면 kubectl get 출력 내에서 읽을 수 있는 형식으로 시크릿을 보고 이러한 모든 문제를 방지할 수 있습니다.

프로젝트 문서는 curl을 사용하여 GitHub에서 바이너리를 가져와 경로에 추가할 것을 권장합니다. 이는 다양한 민감한 데이터에 영향을 미치므로 소스에서 컴파일하고 먼저 소스를 검토하길 권장합니다. 다행히 이 플러그인은 형식이 적절히 지정된 단일 소스 파일로 구성됩니다.

git clone git@github.com:ashleyschuett/kubernetes-secret-decode.git
cd kubernetes-secret-decode
GO111MODULE=off go build -o $GOPATH/bin/kubectl-ksd

플러그인으로 인식되려면 마지막 단계에 빌드한 바이너리 이름이 kubectl-로 시작해야 합니다. $GOPATH/bin이 $PATH에 있는지 확인한 후 다음과 같이 사용할 수 있습니다.

kubectl ksd get secret -n <namespace-name> <secret-name> -o yaml

4. 최근 및 이전 로그

몇 주 또는 몇 달의 가동 시간을 달성 가능한 서비스를 보유한 경우 컨테이너 로그는 일반적 kubectl 로그가 명령어가 엄청난 양의 출력을 생성하는 크기로 증가할 수 있습니다. 텍스트를 그리는 터미널의 기능적 한계를 테스트하는 것처럼 느끼거나 사람이 읽을 수 있어야 하는 네트워크 트래픽의 양에 놀라실 수 있습니다. 이러한 경우 출력을 줄이고 원하는 메시지를 얻을 수 있는 여러 방법이 있습니다.

첫 번째는 --tail=N 플래그로, 파일의 가장 최근 줄 N개를 표시하기 시작합니다.

kubectl logs --tail=10 -f -n kube-system -l component=kube-apiserver

또한 --since=time 30초, 1시간 또는 5분 등의 시간 간격을 허용하여 각각 여러 초, 시간 또는 분을 나타냅니다.

kubectl logs --since=5m -f -n kube-system -l component=kube-apiserver

제가 의존하게 된 또 다른 로그 플래그는 -p입니다. 이것은 종료한 컨테이너의 로그인 컨테이너의 이전 실행 로그를 표시합니다. 제가 포드를 재시작하고 다시 크래시되기 전에 빠른 마우스 및 키보드 동작으로 로그를 “catch”하려 시도할 때, 이 기능이 있었다면 Kubernetes를 처음 사용한 며칠의 경험이 훨씬 간편했을 겁니다.

kubectl logs -p -n kube-system -l component=etcd

5. 기다리는 동안 시간 단축

sleep 명령어를 사용하여 루프를 작성하고 싶을 때는 일반적으로 더 좋은 방법이 있습니다. 어떤 간격을 선택하든 1초 이상 낭비할 가능성이 있습니다. 자동화된 프로세스인 경우 그 시간이 누적될 수 있습니다. kubectl wait 명령어 및 관련 apimachinery 패키지가 필요한 이유입니다. 이 명령어를 사용하면 클러스터에서 조건이 충족되는 데 필요한 특정 시간 동안 스크립트를 중단할 수 있습니다. 또한 새 릴리스가 클러스터에 도달하는 순간 Slack에 에어 혼을 게시하는 데 사용할 수도 있습니다. 즐겁게 사용하십시오.

다음은 몇 가지 예시입니다.

kubectl wait --for=condition=Available deployment/metrics-server
kubectl wait --for=condition=Initialized pod/csi-linode-controller-0

사용 가능한 조건은 리소스 유형에 따라 다르며 “Conditions:”에서 kubectl describe를 사용하여 검색할 수 있습니다. 제공된 리소스는 동시에 많은 여러 개의 다른 조건을 가질 수 있습니다.

보너스 팁!

때때로 출력을 보고 추가 네트워킹 또는 기타 정보가 표시되길 바랄 때가 있습니다, 그렇죠? 도움을 받으려면 명령어에 -owide를 추가해 보십시오. 이는 거의 모든 리소스 유형에 적용되며 표시되는 열은 CRD( 사용자 지정 리소스 정의)에 맞게 사용자 지정할 수 있습니다. 예시:

kubectl get pods -A -owide
kubectl get services -A -owide

마지막으로, 지금까지 알아차리지 못하셨다면 -A는 해당 플래그의 별칭으로 추가되었습니다. --all-namespaces. 이 기능만으로도 기능이 도입된 후 전 세계적으로 수백만 번의 키 입력을 절감할 수 있었을 듯합니다. 시간을 단축할 수 있는 또 다른 방법은, alias k=kubectl 쉘 rc에 추가하는 것입니다.

이 게시물에서는 주로 기본적인 kubectl 기능을 다루었습니다. 더 심층적인 내용은 온라인으로 읽을 수 있는 오픈소스 kubectl 도서를 참조하십시오. Kubernetes 리소스를 관리하고 구성할 수 있는 기본 제공 도구인 Kustomize 사용을 중점적으로 다룹니다. 특히 취약성이 최소화된 노출 영역이 있는 Kubernetes 프로젝트 프레임워크를 찾고 있는 분들께 강력히 추천드립니다. 다른 유용한 명령어 모음은 kubectl 플러그인 공식 패키지 매니저인 Krew에서 확인하십시오.


댓글 (2)

  1. Author Photo

    Great post Andrew, this is actually cool.

    #2, getting memory usage based on namespace is a nice hack, on #3, i’d prefer to use rancher to get most of these information.

    What do you think, have you tried rancher before?

  2. Andrew Sauber

    Thanks : )

    I have used Rancher before, in fact Linode has an official Rancher integration which you can read about here: https://www.linode.com/docs/kubernetes/how-to-deploy-kubernetes-on-linode-with-rancher-2-x/

    I do like Rancher for managing access to a cluster, the fact that each user gets a ServiceAccount token proxied through the Rancher deployment is very cool.

    For viewing secrets, I still use the technique in #3.

댓글 남기기

이메일 주소는 게시되지 않습니다. 필수 필드가 표시됩니다 *