kubectl을 보다 효과적으로 사용하는 방법: 자세한 가이드

쿠버네티스를 사용하신다면 kubectl은 아마도 가장 많이 사용하는 도구 중 하나일 것입니다. 특정 도구를 다루는 데 많은 시간을 투자할 때마다 해당 도구를 제대로 배우고 효과적으로 사용하는 방법을 익히는 것이 중요합니다.

팀 Mail.ru의 Kubernetes aaS 다니엘 바이벨의 글을 번역했습니다. 이 글에는 kubectl을 효과적으로 사용하는 데 필요한 팁과 요령이 담겨 있습니다. 또한 쿠버네티스의 작동 방식을 더 잘 이해하는 데 도움이 될 것입니다.

저자에 따르면, 이 기사의 목적은 Kubernetes를 사용하여 일상 업무를 보다 효율적으로 수행할 수 있을 뿐만 아니라, 보다 즐겁게 수행할 수 있도록 돕는 것입니다!

소개: kubectl이란 무엇입니까?

kubectl을 보다 효과적으로 사용하는 방법을 배우기 전에 kubectl이 무엇이고 어떻게 작동하는지에 대한 기본적인 이해가 필요합니다.

사용자 관점에서 kubectl은 Kubernetes 작업을 수행할 수 있는 제어판입니다.

기술적으로 말하면 kubectl은 Kubernetes API 클라이언트입니다.

쿠버네티스 API는 HTTP REST API입니다. 이 API는 쿠버네티스의 실제 사용자 인터페이스이며, 쿠버네티스를 완벽하게 제어합니다. 즉, 모든 쿠버네티스 작업은 API 엔드포인트로 표현되며 해당 엔드포인트에 대한 HTTP 요청을 통해 수행될 수 있습니다.

따라서 kubectl의 주요 작업은 Kubernetes API에 HTTP 요청을 하는 것입니다.

쿠버네티스는 완전한 리소스 지향 시스템입니다. 즉, 내부 리소스 상태를 유지하며 모든 쿠버네티스 작업은 CRUD 작업입니다.

이러한 리소스를 관리함으로써 Kubernetes를 완벽하게 제어할 수 있으며, Kubernetes는 리소스의 현재 상태를 기반으로 작업을 수행합니다. 이러한 이유로 Kubernetes API 참조는 리소스 유형과 관련 작업 목록으로 구성됩니다.

예를 살펴보자.

ReplicaSet 리소스를 생성하려고 한다고 가정해 보겠습니다. 이를 위해 ReplicaSet을 다음 이름의 파일에 설명합니다. replicaset.yaml그런 다음 명령을 실행합니다.

$ kubectl create -f replicaset.yaml

이렇게 하면 ReplicaSet 리소스가 생성됩니다. 그런데 이 과정에서는 어떤 일이 일어날까요?

쿠버네티스에는 ReplicaSet 생성 작업이 있습니다. 다른 작업과 마찬가지로 이 작업도 API 엔드포인트로 제공됩니다. 이 작업의 구체적인 API 엔드포인트는 다음과 같습니다.

POST /apis/apps/v1/namespaces/{namespace}/replicasets

모든 Kubernetes 작업에 대한 API 엔드포인트는 다음에서 찾을 수 있습니다. API 참조 (포함 위의 종점). 엔드포인트에 대한 실제 요청을 하려면 먼저 API 참조에 나열된 엔드포인트 경로에 API 서버 URL을 추가해야 합니다.

따라서 위 명령을 실행하면 kubectl은 위 API 엔드포인트로 HTTP POST 요청을 전송합니다. replicaset.yaml, 요청 본문에 전달됩니다.

쿠버네티스 클러스터와 상호 작용하는 모든 명령에 대해 kubectl이 작동하는 방식은 다음과 같습니다. 이 모든 경우에 kubectl은 단순히 적절한 쿠버네티스 API 엔드포인트로 HTTP 요청을 전송합니다.

다음과 같은 유틸리티를 사용하여 Kubernetes를 완전히 관리할 수 있습니다. curlKubernetes API에 HTTP 요청을 수동으로 전송합니다. Kubectl은 Kubernetes API 사용을 더욱 간편하게 만들어줍니다.

kubectl의 기본 원리와 작동 방식을 살펴보겠습니다. 하지만 모든 kubectl 사용자가 쿠버네티스 API에 대해 알아야 할 몇 가지 사항이 더 있습니다. 쿠버네티스의 내부 작동 방식을 간략하게 살펴보겠습니다.

쿠버네티스의 내부 세계

쿠버네티스는 클러스터 노드에서 별도의 프로세스로 실행되는 독립적인 구성 요소 집합으로 구성됩니다. 일부 구성 요소는 마스터 노드에서 실행되고, 다른 구성 요소는 워커 노드에서 실행되며, 각 구성 요소는 고유한 전문화된 작업을 수행합니다.

마스터 노드의 가장 중요한 구성 요소는 다음과 같습니다.

1. 둥근 천장 — 리소스 정의를 저장합니다(보통은 etcd야).
2. API 서버 — API를 제공하고 저장소를 관리합니다.
3. 컨트롤러 관리자 - 리소스 상태가 사양을 준수하는지 확인합니다.
4. 스케줄러 - 워커 노드에 포드를 예약합니다.

워커 노드에서 가장 중요한 구성 요소 중 하나는 다음과 같습니다.

1. 쿠벨렛 — 워커 노드에서 컨테이너 실행을 관리합니다.

이러한 구성 요소가 어떻게 함께 작동하는지 이해하기 위해 예를 살펴보겠습니다.

방금 완료했다고 가정해 보겠습니다. kubectl create -f replicaset.yaml, 그 후 kubectl이 HTTP POST 요청을 했습니다. ReplicaSet API 엔드포인트 (ReplicaSet 리소스 정의 전달).

클러스터 내에서는 무슨 일이 일어나고 있나요?

1. 한 후 kubectl create -f replicaset.yaml API 서버는 ReplicaSet 리소스 정의를 저장소에 저장합니다.

   

2. 다음으로, ReplicaSet 리소스의 생성, 수정 및 삭제를 처리하는 컨트롤러 관리자에서 ReplicaSet 컨트롤러가 시작됩니다.

   

3. ReplicaSet 컨트롤러는 ReplicaSet 정의의 포드 템플릿에 따라 ReplicaSet의 각 복제본에 대한 포드 정의를 생성하고 이를 저장소에 저장합니다.

   

4. 스케줄러가 시작되어 아직 어떤 작업자 노드에도 할당되지 않은 포드를 모니터링합니다.

   

5. 스케줄러는 각 포드에 적합한 워커 노드를 선택하고 이 정보를 스토리지의 포드 정의에 추가합니다.

   

6. 포드가 할당된 작업자 노드에서 Kubelet이 실행되어 해당 노드에 할당된 포드를 모니터링합니다.

   

7. Kubelet은 저장소에서 Pod 정의를 읽고 Docker와 같은 컨테이너 런타임에 노드에서 컨테이너를 시작하도록 지시합니다.

   

아래는 이 설명의 텍스트 버전입니다.

ReplicaSet 생성 엔드포인트에 대한 API 요청은 API 서버에서 처리됩니다. API 서버는 요청을 인증하고 ReplicaSet 리소스 정의를 저장소에 저장합니다.

이 이벤트는 컨트롤러 관리자의 하위 프로세스인 ReplicaSet 컨트롤러를 시작합니다. ReplicaSet 컨트롤러는 저장소에서 ReplicaSet 리소스의 생성, 업데이트 및 삭제를 모니터링하고, 이러한 상황이 발생하면 이벤트 알림을 수신합니다.

ReplicaSet 컨트롤러의 역할은 필요한 수의 ReplicaSet 포드가 존재하는지 확인하는 것입니다. 이 예시에서는 포드가 아직 존재하지 않으므로 ReplicaSet 컨트롤러는 ReplicaSet 정의의 포드 템플릿에 따라 이러한 포드 정의를 생성하여 스토리지에 저장합니다.

새 Pod를 생성하면 스케줄러가 트리거되어 아직 워커 노드에 스케줄링되지 않은 Pod 정의를 모니터링합니다. 스케줄러는 각 Pod에 적합한 워커 노드를 선택하고 저장소에 Pod 정의를 업데이트합니다.

지금까지 클러스터의 어느 곳에서도 워크로드 코드가 실행되지 않았습니다. 지금까지 수행된 모든 작업은 - 이는 마스터 노드의 저장소에서 리소스를 생성하고 업데이트하는 것입니다.

마지막 이벤트는 Kubelet을 트리거하는데, Kubelet은 워커 노드에 예약된 파드를 모니터링합니다. ReplicaSet 파드가 설치된 워커 노드의 Kubelet은 Docker와 같은 컨테이너 런타임에 필요한 컨테이너 이미지를 다운로드하여 실행하도록 지시해야 합니다.

이제 ReplicaSet 애플리케이션이 마침내 실행됩니다!

쿠버네티스 API의 역할

이전 예에서 보았듯이 Kubernetes 구성 요소(API 서버 및 저장소 제외)는 저장소의 리소스에 대한 변경 사항을 감시하고 저장소의 리소스에 대한 정보를 변경합니다.

물론, 이러한 구성 요소는 저장소와 직접 상호 작용하지 않고 Kubernetes API를 통해서만 상호 작용합니다.

다음 예를 고려해 보겠습니다.:

1. ReplicaSet 컨트롤러는 API 엔드포인트를 사용합니다. ReplicaSets 목록 매개변수 포함 watch ReplicaSet 리소스의 변경 사항을 모니터링합니다.
2. ReplicaSet 컨트롤러는 API 엔드포인트를 사용합니다. 포드 생성 (pod 생성) pod를 생성합니다.
3. 스케줄러는 API 엔드포인트를 사용합니다. 패치 포드 (pod 변경) 선택한 작업자 노드에 대한 정보로 pod를 업데이트합니다.

보시다시피, 이는 kubectl이 액세스하는 것과 동일한 API입니다. 동일한 API를 사용하여 내부 구성 요소와 외부 사용자를 실행하는 것은 쿠버네티스의 기본 설계 개념입니다.

이제 Kubernetes가 작동하는 방식을 요약해 보겠습니다.

1. 저장소는 상태, 즉 Kubernetes 리소스를 저장합니다.
2. API 서버는 Kubernetes API 형태로 저장소에 대한 인터페이스를 제공합니다.
3. 다른 모든 Kubernetes 구성 요소와 사용자는 API를 통해 Kubernetes 상태(리소스)를 읽고, 관찰하고, 조작합니다.

이러한 개념을 알면 kubectl을 더 잘 이해하고 최대한 활용하는 데 도움이 됩니다.

이제 kubectl을 사용하여 생산성을 향상시키는 데 도움이 되는 몇 가지 구체적인 팁과 요령을 살펴보겠습니다.

1. 명령 완성으로 타이핑 속도 향상

kubectl 생산성을 향상시키는 데 가장 유용하면서도 종종 간과되는 기술 중 하나가 명령 완성입니다.

명령 완성 기능을 사용하면 Tab 키를 사용하여 kubectl 명령의 일부를 자동으로 완성할 수 있습니다. 이 기능은 리소스 이름과 같은 복잡한 명령을 포함하여 하위 명령, 옵션 및 인수에 적용됩니다.

kubectl 명령 완성이 어떻게 작동하는지 확인하세요.

명령어 완성은 Bash 및 Zsh 셸에서 작동합니다.

공식 가이드 자동완성을 설정하는 방법에 대한 자세한 설명이 포함되어 있지만, 아래에서는 간략하게 발췌한 내용만 제공합니다.

명령 완성 작동 방식

명령 완성은 완성 스크립트를 사용하여 작동하는 셸 기능입니다. 완성 스크립트는 특정 명령의 완성 동작을 정의하는 셸 스크립트입니다.

Kubectl은 다음 명령을 사용하여 Bash 및 Zsh에 대한 완성 스크립트를 자동으로 생성하고 출력합니다.

$ kubectl completion bash

Или :

$ kubectl completion zsh

이론상으로는 이러한 명령의 출력을 적절한 셸로 파이프해서 kubectl이 명령을 보완할 수 있도록 해야 합니다.

На практике — способ подключения отличается для Bash (включая различия между Linux и MacOS) и Zsh. Ниже мы рассмотрим все эти варианты.

Bash в Linux

Bash 완성 스크립트는 bash-completion 패키지에 따라 달라지므로 먼저 해당 패키지를 설치해야 합니다.

$ sudo apt-get install bash-completion

Или :

$ yum install bash-completion

다음 명령을 사용하여 패키지가 성공적으로 설치되었는지 테스트할 수 있습니다.

$ type _init_completion

셸 함수 코드가 출력되면 bash 자동 완성 기능이 제대로 설치된 것입니다. 명령이 "찾을 수 없음" 오류를 반환하는 경우, 다음 줄을 파일에 추가해야 합니다. ~ / .bashrc:

$ source /usr/share/bash-completion/bash_completion

이 줄을 파일에 추가해야 합니까? ~ / .bashrc bash-completion을 설치하는 데 사용한 패키지 관리자에 따라 달라집니다. APT의 경우 필수이지만, YUM의 경우 필수가 아닙니다.

bash-completion을 설치한 후에는 모든 셸 세션에서 kubectl 완성 스크립트가 활성화되도록 구성해야 합니다.

이를 수행하는 한 가지 방법은 다음 줄을 파일에 추가하는 것입니다. ~ / .bashrc:

source <(kubectl completion bash)

또 다른 방법은 kubectl 애드온 스크립트를 디렉토리에 추가하는 것입니다. /etc/bash_completion.d (존재하지 않으면 만듭니다):

$ kubectl completion bash >/etc/bash_completion.d/kubectl

카탈로그의 모든 추가 스크립트 /etc/bash_completion.d bash-completion에 자동으로 포함됩니다.

두 옵션 모두 동등하게 적용됩니다.

셸을 재시작하면 kubectl 명령 완성이 작동합니다.

MacOS의 Bash

MacOS에서는 설정이 조금 더 복잡합니다. MacOS는 기본적으로 Bash 버전 3.2를 사용하고, kubectl 자동 완성 스크립트는 Bash 버전 4.1 이상을 요구하며 Bash 3.2에서는 작동하지 않습니다.

MacOS에서 이전 버전의 Bash를 사용하는 이유는 라이선스 문제 때문입니다. Bash 버전 4는 Apple이 지원하지 않는 GPLv3 라이선스를 따릅니다.

MacOS에서 kubectl 자동 완성을 설정하려면 최신 버전의 Bash를 설치해야 합니다. 업데이트된 Bash를 기본 셸로 설정하면 나중에 많은 번거로움을 덜 수 있습니다. 방법은 간단합니다. "MacOS에서 Bash 업데이트".

계속하기 전에 최신 버전의 Bash를 사용하고 있는지 확인하십시오(출력 확인) bash --version).

Bash 자동 완성 스크립트는 프로젝트별로 다릅니다. bash 완성, 먼저 설치해야 합니다.

다음을 사용하여 bash-completion을 설치할 수 있습니다. 사제:

$ brew install bash-completion@2

여기에 @2 bash-completion 버전 2를 의미합니다. kubectl 완성에는 bash-completion v2가 필요하고, bash-completion v2에는 최소 Bash 버전 4.1이 필요합니다.

명령 출력 brew-install 파일에 추가해야 할 내용을 지정하는 Caveats 섹션이 포함되어 있습니다. ~/.bash_profile:

export BASH_COMPLETION_COMPAT_DIR=/usr/local/etc/bash_completion.d
[[ -r "/usr/local/etc/profile.d/bash_completion.sh" ]] && . 
"/usr/local/etc/profile.d/bash_completion.sh"

하지만 나는 이 줄들을 추가하는 것을 권장합니다. ~/.bash_profile, 및 c ~/.bashrc. 이 경우 자동 완성 기능은 기본 명령 셸뿐만 아니라 자식 명령 셸에서도 사용할 수 있습니다.

명령 셸을 다시 시작한 후 다음 명령을 사용하여 설치가 올바른지 확인할 수 있습니다.

$ type _init_completion

출력에서 셸 함수가 보이면 모든 것이 올바르게 설정된 것입니다.

이제 모든 세션에서 kubectl 자동 완성이 활성화되었는지 확인해야 합니다.

한 가지 방법은 다음 줄을 추가하는 것입니다. ~/.bashrc:

source <(kubectl completion bash)

두 번째 방법은 폴더에 자동완성 스크립트를 추가하는 것입니다. /usr/local/etc/bash_completion.d:

$ kubectl completion bash
>/usr/local/etc/bash_completion.d/kubectl

이 방법은 Homebrew를 사용하여 bash-completion을 설치한 경우에만 작동합니다. 이 경우, bash-completion은 이 디렉터리의 모든 스크립트를 로드합니다.

설치한 경우 Homebrew를 사용한 kubectl, 자동 완성 스크립트가 자동으로 폴더에 배치되므로 이전 단계를 수행할 필요가 없습니다. /usr/local/etc/bash_completion.d 설치 중에. 이 경우, bash-completion을 설치하자마자 kubectl 완성이 작동하기 시작합니다.

결국, 이 모든 옵션은 동등합니다.

Zsh

Zsh 완성 스크립트는 종속성을 필요로 하지 않습니다. 셸을 시작할 때 해당 종속성을 활성화하기만 하면 됩니다.

줄을 추가하여 이 작업을 수행할 수 있습니다. ~/.zshrc 파일:

source <(kubectl completion zsh)

오류가 발생하는 경우 not found: compdef 쉘을 재부팅한 후 내장 기능을 활성화해야 합니다. compdef파일의 시작 부분에 추가하면 활성화할 수 있습니다. ~/.zshrc 다음 :

autoload -Uz compinit
compinit

2. 리소스 사양을 빠르게 확인하세요

YAML 리소스 정의를 생성할 때는 해당 리소스의 필드와 그 의미를 알아야 합니다. 이 정보는 모든 리소스에 대한 전체 사양이 포함된 API 참조에서 찾을 수 있습니다.

하지만 무언가를 검색할 때마다 웹 브라우저로 전환하는 것은 불편합니다. 그래서 kubectl은 다음 명령을 제공합니다. kubectl explain모든 리소스의 사양을 터미널에서 바로 보여줍니다.

명령 형식은 다음과 같습니다.

$ kubectl explain resource[.field]...

이 명령은 요청된 리소스 또는 필드의 사양을 출력합니다. 출력되는 정보는 API 매뉴얼에 포함된 정보와 동일합니다.

기본적으로 kubectl explain 필드 중첩의 첫 번째 수준만 표시합니다.

그것이 어떻게 생겼는지 보세요 여기있을 수 있습니다..

옵션을 추가하면 전체 트리를 표시할 수 있습니다. --recursive:

$ kubectl explain deployment.spec --recursive

필요한 리소스가 정확히 무엇인지 모르는 경우 다음 명령을 사용하여 모든 리소스를 표시할 수 있습니다.

$ kubectl api-resources

이 명령은 리소스 이름을 복수형으로 표시합니다. 예: deployments 대신 deployment. 또한 다음과 같은 짧은 이름도 표시됩니다. deploy, 리소스에 해당 옵션이 있는 경우. 이러한 차이점은 걱정하지 마세요. 이러한 모든 명명 옵션은 kubectl에서 동일합니다. 즉, 어떤 옵션을 사용하든 kubectl explain.

다음 명령은 모두 동일합니다.

$ kubectl explain deployments.spec
# или
$ kubectl explain deployment.spec
# или        
$ kubectl explain deploy.spec

3. 사용자 정의 열 출력 형식 사용

기본 명령 출력 형식은 다음과 같습니다. kubectl get:

$ kubectl get pods
NAME                     READY    STATUS    RESTARTS  AGE
engine-544b6b6467-22qr6   1/1     Running     0       78d
engine-544b6b6467-lw5t8   1/1     Running     0       78d
engine-544b6b6467-tvgmg   1/1     Running     0       78d
web-ui-6db964458-8pdw4    1/1     Running     0       78d

이 형식은 편리하지만, 포함되는 정보의 양이 제한적입니다. 전체 리소스 정의 형식과 비교했을 때, 여기에는 표시되는 필드가 몇 개뿐입니다.

이 경우 사용자 지정 열 출력 형식을 사용할 수 있습니다. 출력할 데이터를 정의할 수 있습니다. 모든 리소스 필드를 별도의 열로 출력할 수 있습니다.

사용자 정의 형식의 사용은 다음 옵션에 따라 결정됩니다.

-o custom-columns=<header>:<jsonpath>[,<header>:<jsonpath>]...

각 출력 열을 쌍으로 정의할 수 있습니다. <header>:<jsonpath>어디에서 <header> — 열 이름 및 <jsonpath> — 리소스 필드를 정의하는 표현식입니다.

간단한 예를 살펴보겠습니다.

$ kubectl get pods -o custom-columns='NAME:metadata.name'

NAME
engine-544b6b6467-22qr6
engine-544b6b6467-lw5t8
engine-544b6b6467-tvgmg
web-ui-6db964458-8pdw4

출력에는 포드 이름이 포함된 열이 하나 있습니다.

옵션의 표현식은 필드에서 포드 이름을 선택합니다. metadata.name이는 포드 이름이 자식 필드 이름 필드에 정의되어 있기 때문입니다. metadata 포드 리소스 설명에서 확인할 수 있습니다. 자세한 내용은 다음에서 확인할 수 있습니다. API 매뉴얼 또는 명령을 입력하세요 kubectl explain pod.metadata.name.

이제 출력에 열을 추가하고 싶다고 가정해 보겠습니다. 예를 들어 각 Pod가 실행 중인 노드를 표시하고 싶을 수 있습니다. 이렇게 하려면 사용자 지정 열 옵션에 적절한 열 사양을 추가하기만 하면 됩니다.

$ kubectl get pods 
  -o custom-columns='NAME:metadata.name,NODE:spec.nodeName'

NAME                       NODE
engine-544b6b6467-22qr6    ip-10-0-80-67.ec2.internal
engine-544b6b6467-lw5t8    ip-10-0-36-80.ec2.internal
engine-544b6b6467-tvgmg    ip-10-0-118-34.ec2.internal
web-ui-6db964458-8pdw4     ip-10-0-118-34.ec2.internal

표현식은 노드 이름을 선택합니다. spec.nodeName - 포드가 노드에 할당되면 해당 이름이 필드에 기록됩니다. spec.nodeName 포드의 리소스 사양입니다. 더 자세한 정보는 출력에서 ​​확인할 수 있습니다. kubectl explain pod.spec.nodeName.

Kubernetes 리소스 필드는 대소문자를 구분합니다.

모든 리소스 필드를 열로 볼 수 있습니다. 리소스 사양을 확인하고 원하는 필드에 적용해 보세요.

하지만 먼저 필드 선택 표현식을 자세히 살펴보겠습니다.

JSONPath 표현식

리소스 필드를 선택하기 위한 표현식은 다음을 기반으로 합니다. JSON경로.

JSONPath는 JSON 문서에서 데이터를 검색하는 언어입니다. JSONPath의 가장 간단한 사용 사례는 단일 필드를 선택하는 것입니다. 더 많은 가능성선택기, 필터 등을 포함합니다.

Kubectl explain은 제한된 수의 JSONPath 기능을 지원합니다. 기능과 사용 예는 다음과 같습니다.

# Выбрать все элементы списка
$ kubectl get pods -o custom-columns='DATA:spec.containers[*].image'
# Выбрать специфический элемент списка
$ kubectl get pods -o custom-columns='DATA:spec.containers[0].image'
# Выбрать элементы списка, попадающие под фильтр
$ kubectl get pods -o custom-columns='DATA:spec.containers[?(@.image!="nginx")].image'
# Выбрать все поля по указанному пути, независимо от их имени
$ kubectl get pods -o custom-columns='DATA:metadata.*'
# Выбрать все поля с указанным именем, вне зависимости от их расположения
$ kubectl get pods -o custom-columns='DATA:..image'

특히 중요한 것은 [] 연산자입니다. 많은 쿠버네티스 리소스 필드는 목록이며, 이 연산자를 사용하면 해당 목록의 요소를 선택할 수 있습니다. [*]와 같은 와일드카드와 함께 사용하여 목록의 모든 요소를 ​​선택하는 경우가 많습니다.

적용 사례

사용자 지정 열 출력 형식을 사용할 수 있는 가능성은 무궁무진합니다. 출력에 원하는 필드 또는 리소스 필드 조합을 표시할 수 있습니다. 몇 가지 예시를 보여드리겠지만, 직접 탐색하여 자신에게 맞는 응용 프로그램을 찾아보세요.

1. 포드에 대한 컨테이너 이미지 표시:

   $ kubectl get pods 
     -o custom-columns='NAME:metadata.name,IMAGES:spec.containers[*].image'
   
   NAME                        IMAGES
   engine-544b6b6467-22qr6     rabbitmq:3.7.8-management,nginx
   engine-544b6b6467-lw5t8     rabbitmq:3.7.8-management,nginx
   engine-544b6b6467-tvgmg     rabbitmq:3.7.8-management,nginx
   web-ui-6db964458-8pdw4      wordpress

   이 명령은 각 포드의 컨테이너 이미지 이름을 표시합니다.

   포드에는 여러 개의 컨테이너가 포함될 수 있으며, 이 경우 이미지 이름은 쉼표로 구분하여 한 줄에 나열됩니다.

2. 노드 가용성 영역 표시:

   $ kubectl get nodes 
     -o 
   custom-columns='NAME:metadata.name,ZONE:metadata.labels.failure-domain.beta.kubernetes.io/zone'
   
   NAME                          ZONE
   ip-10-0-118-34.ec2.internal   us-east-1b
   ip-10-0-36-80.ec2.internal    us-east-1a
   ip-10-0-80-67.ec2.internal    us-east-1b

   이 명령은 클러스터가 퍼블릭 클라우드에 호스팅된 경우 유용합니다. 각 노드의 가용성 영역을 표시합니다.

   가용성 영역은 복제 영역을 특정 지리적 지역으로 제한하는 클라우드 개념입니다.

   각 노드의 가용성 영역은 특수 레이블을 통해 얻어집니다. failure-domain.beta.kubernetes.io/zone클러스터가 퍼블릭 클라우드에서 실행되는 경우 이 레이블은 자동으로 생성되고 각 노드의 가용성 영역 이름으로 채워집니다.

   레이블은 Kubernetes 리소스 사양의 일부가 아니므로 레이블에 대한 정보를 찾을 수 없습니다. API 매뉴얼. 하지만 YAML 또는 JSON 형식으로 노드 정보를 요청하면 다른 레이블과 마찬가지로 볼 수 있습니다.

   $ kubectl get nodes -o yaml
   # или
   $ kubectl get nodes -o json

   이는 리소스 사양을 연구하는 것 외에도 리소스에 대해 더 많이 알아볼 수 있는 좋은 방법입니다.

4. 클러스터와 네임스페이스 간 쉬운 전환

kubectl이 Kubernetes API에 요청을 하면 먼저 kubeconfig 파일을 읽어 연결에 필요한 모든 매개변수를 가져옵니다.

기본적으로 kubeconfig 파일은 ~/.kube/config이 파일은 일반적으로 특수 명령에 의해 생성되거나 업데이트됩니다.

여러 클러스터를 사용하는 경우 kubeconfig 파일에 모든 클러스터에 대한 연결 설정이 포함됩니다. kubectl 명령에 어떤 클러스터를 사용하는지 알려줄 방법이 필요합니다.

클러스터 내에서 여러 개의 네임스페이스를 생성할 수 있습니다. 이는 물리적 클러스터 내에 가상 클러스터와 같은 개념입니다. Kubectl은 kubeconfig 파일을 기반으로 어떤 네임스페이스를 사용할지 결정합니다. 즉, kubectl에게 어떤 네임스페이스를 사용할지 알려주는 방법도 필요합니다.

이 장에서는 이 기능이 어떻게 작동하는지, 그리고 효과적인 작업을 수행하는 방법을 설명하겠습니다.

KUBECONFIG 환경 변수에 여러 kubeconfig 파일을 나열할 수 있습니다. 이 경우 모든 파일은 런타임에 하나의 공통 구성으로 병합됩니다. kubectl을 실행하여 기본 kubeconfig 파일을 변경할 수도 있습니다. --kubeconfig. 보다 공식 문서.

kubeconfig 파일

kubeconfig 파일에 정확히 무엇이 포함되어 있는지 살펴보겠습니다.

보시다시피 kubeconfig 파일에는 컨텍스트 집합이 포함되어 있습니다. 컨텍스트는 다음 세 가지 요소로 구성됩니다.

• 클러스터 - 클러스터 서버 API의 URL입니다.
• 사용자 - 클러스터의 사용자 인증 자격 증명입니다.
• 네임스페이스 - 클러스터에 가입할 때 사용되는 네임스페이스입니다.

실제로는 kubeconfig 파일에서 클러스터당 하나의 컨텍스트를 사용하는 것이 일반적입니다. 하지만 사용자 또는 네임스페이스별로 클러스터당 여러 컨텍스트를 사용할 수 있습니다. 그러나 이러한 다중 컨텍스트 구성은 흔하지 않으므로 일반적으로 클러스터와 컨텍스트 간에 일대일 매핑이 적용됩니다.

언제든지 다음 컨텍스트 중 하나가 현재 상태입니다.

kubectl은 구성 파일을 읽을 때 항상 현재 컨텍스트에서 정보를 가져옵니다. 위 예에서 kubectl은 Hare 클러스터에 연결합니다.

따라서 다른 클러스터로 전환하려면 kubeconfig 파일에서 현재 컨텍스트를 변경해야 합니다.

이제 kubectl이 Fox 클러스터에 연결됩니다.

동일한 클러스터의 다른 네임스페이스로 전환하려면 현재 컨텍스트에 대한 네임스페이스 요소의 값을 변경해야 합니다.

위의 예에서 kubectl은 Fox 클러스터의 Prod 네임스페이스를 사용합니다(Test 네임스페이스는 이전에 설정됨).

kubectl도 옵션을 제공한다는 점에 유의하세요. --cluster, --user, --namespace и --contextkubeconfig 파일에 설정된 내용과 관계없이 개별 요소와 현재 컨텍스트 자체를 덮어쓸 수 있는 기능을 제공합니다. kubectl options.

이론적으로는 kubeconfig 파일에서 매개변수를 수동으로 변경할 수 있습니다. 하지만 이는 불편합니다. 이러한 작업을 간소화하기 위해 매개변수를 자동으로 변경할 수 있는 다양한 유틸리티가 있습니다.

kubectx를 사용하세요

클러스터와 네임스페이스를 전환하는 데 매우 인기 있는 유틸리티입니다.

이 유틸리티는 명령을 제공합니다 kubectx и kubens 각각 현재 컨텍스트와 네임스페이스를 변경합니다.

앞서 언급했듯이, 클러스터당 컨텍스트가 하나만 있는 경우 현재 컨텍스트를 변경하면 클러스터도 변경됩니다.

다음은 이러한 명령을 실행하는 예입니다.

기본적으로 이러한 명령은 위에서 설명한 대로 kubeconfig 파일을 편집합니다.

설치하기 위해서 kubectx, 지침을 따르세요 기둥.

두 명령 모두 컨텍스트 및 네임스페이스 이름 자동 완성을 지원하므로 이름을 모두 입력할 필요가 없습니다. 자동 완성 설정 지침 여기에.

또 다른 유용한 기능 kubectx 이 대화형 모드. 유틸리티와 함께 ​​작동합니다. fzf, 별도로 설치해야 합니다. fzf를 설치하면 자동으로 대화형 모드가 사용 가능해집니다. kubectx대화형 모드에서는 fzf가 제공하는 대화형 무료 검색 인터페이스를 통해 컨텍스트와 네임스페이스를 선택할 수 있습니다.

셸 별칭 사용

kubectl도 해당 명령을 제공하므로 현재 컨텍스트와 네임스페이스를 변경하기 위해 별도의 도구가 필요하지 않습니다. 따라서 다음 명령을 사용합니다. kubectl config kubeconfig 파일을 편집하기 위한 하위 명령을 제공합니다.

다음은 그 중 일부입니다.

• kubectl config get-contexts: 모든 컨텍스트를 출력합니다.
• kubectl config current-context: 현재 컨텍스트를 가져옵니다.
• kubectl config use-context: 현재 컨텍스트를 변경합니다.
• kubectl config set-context: 컨텍스트 요소를 변경합니다.

하지만 이러한 명령어는 너무 길어서 직접 사용하기 불편합니다. 실행하기 쉬운 셸 별칭을 만들 수 있습니다.

이 명령들을 기반으로 kubectx와 유사한 기능을 제공하는 별칭 세트를 만들었습니다. 실제 동작은 여기에서 확인할 수 있습니다.

별칭은 fzf를 사용하여 대화형 자유 검색 인터페이스(kubectx 대화형 모드와 유사)를 제공합니다. 즉, 다음이 필요합니다. fzf 설치이러한 별칭을 사용합니다.

별칭의 정의는 다음과 같습니다.

# Получить текущий контекст
alias krc='kubectl config current-context'
# Список всех контекстов
alias klc='kubectl config get-contexts -o name | sed "s/^/  /;|^  $(krc)$|s/ /*/"'
# Изменить текущий контекст
alias kcc='kubectl config use-context "$(klc | fzf -e | sed "s/^..//")"'

# Получить текущее пространство имен
alias krn='kubectl config get-contexts --no-headers "$(krc)" | awk "{print $5}" | sed "s/^$/default/"'
# Список всех пространств имен
alias kln='kubectl get -o name ns | sed "s|^.*/|  |;|^  $(krn)$|s/ /*/"'
# Изменить текущее пространство имен
alias kcn='kubectl config set-context --current --namespace "$(kln | fzf -e | sed "s/^..//")"'

이러한 별칭을 설정하려면 위의 정의를 파일에 추가해야 합니다. ~/.bashrc 또는 ~/.zshrc 셸을 재부팅하세요.

플러그인 사용

Kubectl을 사용하면 기본 명령과 동일한 방식으로 실행되는 플러그인을 로드할 수 있습니다. 예를 들어 kubectl-foo 플러그인을 설치하고 다음 명령을 실행하여 실행할 수 있습니다. kubectl foo.

예를 들어 컨텍스트와 네임스페이스를 이런 방식으로 변경하면 편리합니다. kubectl ctx 문맥을 바꾸고 kubectl ns 네임스페이스를 변경합니다.

저는 이런 일을 하는 두 개의 플러그인을 썼습니다.

• kubectl-ctx
• kubectl-ns

플러그인은 이전 섹션의 별칭을 기반으로 작동합니다.

작동 방식은 다음과 같습니다.

플러그인은 fzf를 사용하여 대화형 자유 검색 인터페이스(kubectx 대화형 모드와 유사)를 제공합니다. 즉, 다음이 필요합니다. fzf 설치이러한 별칭을 사용합니다.

플러그인을 설치하려면 이름이 지정된 셸 스크립트를 다운로드해야 합니다. kubectl-ctx и kubectl-ns 예를 들어 PATH 변수에 있는 모든 디렉토리로 이동하여 실행 가능하게 만들 수 있습니다. chmod +x그 후에는 바로 사용하실 수 있습니다. kubectl ctx и kubectl ns.

5. 자동 별칭을 사용하여 입력을 단축합니다.

셸 별칭은 타이핑 속도를 높이는 좋은 방법입니다. 프로젝트 kubectl 별칭 기본 kubectl 명령에 대한 약 800개의 단축키가 포함되어 있습니다.

800개의 별칭을 어떻게 기억해야 할지 궁금하실 겁니다. 하지만 별칭은 아래와 같은 간단한 구조로 만들어졌기 때문에 모두 기억할 필요는 없습니다.

예를 들면 다음과 같습니다

1. kgpooyaml - kubectl get pods oyaml
2. ksysgsvcw — kubectl -n kube-system svc w 가져오기
3. ksysrmcm -kubectl -n kube-system rm cm
4. kgdepallsl - kubectl로 모든 sl 배포하기

보시다시피 별칭은 kubectl 명령의 특정 요소를 나타내는 구성 요소로 이루어져 있습니다. 각 별칭은 기본 명령, 작업 및 리소스에 대한 구성 요소 하나와 매개변수에 대한 구성 요소 여러 개를 가질 수 있습니다. 위 그림과 같이 왼쪽에서 오른쪽으로 이러한 구성 요소를 "채우기만" 하면 됩니다.

현재 상세 다이어그램은 다음 위치에 있습니다. GitHub의. 거기에서도 찾을 수 있습니다 별명 전체 목록.

예를 들어, 별칭 kgpooyamlall은 다음 명령과 동일합니다. kubectl get pods -o yaml --all-namespaces.

옵션의 상대적 순서는 중요하지 않습니다. 명령 kgpooyamlall 명령과 동일하다 kgpoalloyaml.

모든 구성 요소를 별칭으로 사용할 수는 없습니다. 예를 들어 k, kg, klo, ksys, kgpo 또한, 별칭과 일반 명령 또는 옵션을 명령줄에서 결합할 수 있습니다.

예를 들면 다음과 같습니다

1. 대신에 kubectl proxy 글을 쓸 수 있나요? k proxy.
2. 대신에 kubectl get roles 글을 쓸 수 있나요? kg roles (현재 역할 리소스에 대한 별칭은 없습니다).
3. 특정 포드에 대한 데이터를 얻으려면 다음 명령을 사용할 수 있습니다. kgpo my-pod — kubectl get pod my-pod.

일부 별칭은 명령줄에서 인수가 필요합니다. 예를 들어, 별칭은 다음과 같습니다. kgpol 방법 kubectl get pods -l. 옵션 -l 인수가 필요합니다. 레이블 지정입니다. 별칭을 사용하면 다음과 같습니다. kgpol app=ui.

일부 별칭에는 인수가 필요하므로 별칭 a, f, l은 마지막에 사용해야 합니다.

일반적으로 이 방식을 익히면 실행하려는 명령에서 별칭을 직관적으로 파생시킬 수 있어 입력 시간을 크게 절약할 수 있습니다.

설치

kubectl-aliases를 설치하려면 파일을 다운로드해야 합니다. .kubectl_aliases GitHub에서 가져와서 파일에 포함시킵니다. ~/.bashrc 또는 ~/.zshrc:

source ~/.kubectl_aliases

자동 완성

앞서 말씀드렸듯이, 명령줄에서 별칭에 추가 단어를 추가하는 경우가 많습니다. 예를 들면 다음과 같습니다.

$ kgpooyaml test-pod-d4b77b989

kubectl 명령어 완성을 사용하신다면 리소스 이름 같은 항목에 자동 완성 기능을 사용해 보셨을 겁니다. 그런데 별칭을 사용할 때도 자동 완성 기능을 사용할 수 있을까요?

이것은 매우 중요한 질문입니다. 자동 완성이 작동하지 않으면 별칭의 이점 중 일부를 잃게 되기 때문입니다.

답변은 사용하는 셸에 따라 달라집니다.

1. Zsh에서는 별칭에 대한 자동 완성 기능이 기본적으로 작동합니다.
2. 불행히도 Bash의 경우 자동 완성 기능을 작동시키려면 몇 가지 작업이 필요합니다.

Bash에서 별칭에 대한 자동 완성 활성화

Bash의 문제점은 (Tab 키를 누를 때마다) 별칭이 참조하는 명령(예를 들어 Zsh처럼)이 아니라 별칭 자체를 완성하려 한다는 것입니다. 800개의 별칭에 대한 완성 스크립트가 없기 때문에 완성이 작동하지 않습니다.

계획 완전한 별칭 이 문제에 대한 일반적인 해결책을 제공합니다. 별칭 완성 메커니즘에 연결하여 내부적으로 명령의 별칭을 완성하고, 완성된 명령에 대한 완성 옵션을 반환합니다. 즉, 별칭 완성은 전체 명령 완성과 동일하게 작동합니다.

다음으로, complete-alias를 설치하는 방법을 설명하고, 모든 kubectl 별칭에 대해 완성을 활성화하도록 구성하는 방법을 설명하겠습니다.

complete-alias 설치

우선, complete-alias는 다음에 따라 달라집니다. bash 완성. Поэтому перед установкой complete-alias необходимо убедиться, что bash-completion установлен. Инструкции по установке были даны ранее для Linux 그리고 맥OS.

MacOS 사용자를 위한 중요 참고 사항: kubectl 자동 완성 스크립트와 마찬가지로, complete-alias는 MacOS의 기본 버전인 Bash 3.2에서는 작동하지 않습니다. 특히, complete-alias는 bash-completion v2에 의존합니다(brew install bash-completion@2), 최소 Bash 4.1이 필요합니다. 즉, MacOS에서 complete-alias를 사용하려면 최신 버전의 Bash를 설치해야 합니다.

스크립트를 다운로드해야 합니다 bash_completion.sh 으로 GitHub 저장소 그리고 그것을 당신의 파일에 포함시키세요 ~/.bashrc:

source ~/bash_completion.sh

셸을 재시작하면 complete-alias가 완전히 설치됩니다.

kubectl 별칭에 대한 자동 완성 활성화

기술적으로 complete-alias는 셸 기능을 제공합니다. _complete_alias이 함수는 별칭을 확인하고 별칭 명령에 대한 완성 힌트를 반환합니다.

특정 별칭과 함수를 연결하려면 Bash 내장 메커니즘을 사용해야 합니다. 완전한, 설치하려면 _complete_alias 별칭 보수의 함수로서.

예를 들어, kubectl 명령을 의미하는 별칭 k를 살펴보겠습니다. 설치하려면 _complete_alias 이 별칭에 대한 보완 함수로 다음 명령을 실행해야 합니다.

$ complete -F _complete_alias k

그 결과 별칭 k를 자동 완성할 때마다 함수가 호출됩니다. _complete_alias별칭을 확인하고 명령에 대한 완료 힌트를 반환합니다. kubectl.

두 번째 예로 별칭을 사용해 보겠습니다. kg, 즉 kubectl get:

$ complete -F _complete_alias kg

이전 예와 마찬가지로 kg를 자동 완성하면 다음과 같은 완성 제안을 받게 됩니다. kubectl get.

이런 식으로 complete-alias를 시스템의 모든 별칭에 사용할 수 있습니다.

따라서 모든 kubectl 별칭에 대해 자동 완성을 활성화하려면 각 별칭에 대해 위 명령을 실행해야 합니다. 다음 스니펫은 kubectl-aliases를 다음과 같이 설정했다고 가정하고 이를 수행합니다. ~/.kubectl-aliases:

for _a in $(sed '/^alias /!d;s/^alias //;s/=.*$//' ~/.kubectl_aliases); 
do
  complete -F _complete_alias "$_a"
done

이 코드는 다음에 배치해야 합니다. ~/.bashrc셸을 다시 시작하면 800개의 모든 kubectl 별칭에 대해 자동 완성 기능을 사용할 수 있습니다.

6. 플러그인을 사용하여 kubectl 확장

~부터 시작 버전 1.12, kubectl 지원 플러그인 메커니즘추가 명령으로 기능을 확장할 수 있습니다.

당신이 익숙한 경우 Git 플러그인 메커니즘그러면 kubectl 플러그인도 같은 원리로 구축됩니다.

이 장에서는 플러그인을 설치하는 방법, 플러그인을 찾을 수 있는 위치, 그리고 나만의 플러그인을 만드는 방법에 대해 살펴보겠습니다.

플러그인 설치

Kubectl 플러그인은 다음과 같은 이름의 간단한 실행 파일로 배포됩니다. kubectl-x. 접두사 kubectl- 플러그인을 호출할 수 있는 새로운 kubectl 하위 명령이 뒤따릅니다.

예를 들어, hello 플러그인은 다음 이름의 파일로 배포됩니다. kubectl-hello.

플러그인을 설치하려면 파일을 복사해야 합니다. kubectl-x 예를 들어 PATH 변수에 있는 모든 디렉토리로 이동하여 실행 가능하게 만들 수 있습니다. chmod +x. 그 직후에 플러그인을 호출할 수 있습니다. kubectl x.

다음 명령을 사용하면 현재 시스템에 설치된 모든 플러그인을 나열할 수 있습니다.

$ kubectl plugin list

이 명령은 같은 이름의 플러그인이 여러 개 있거나, 실행할 수 없는 플러그인 파일이 있는 경우에도 경고를 표시합니다.

Krew로 플러그인 찾기 및 설치

Kubectl 플러그인은 소프트웨어 패키지처럼 공유하고 재사용할 수 있습니다. 하지만 다른 사람들이 공유한 플러그인은 어디에서 찾을 수 있을까요?

프로젝트 크루 kubectl 플러그인 공유, 검색, 설치 및 관리를 위한 통합 솔루션을 제공하는 것을 목표로 합니다. 이 프로젝트는 스스로를 "kubectl 플러그인 패키지 관리자"라고 부릅니다(Krew는 꾸미다).

Krew는 선택하고 설치할 수 있는 kubectl 플러그인 목록입니다. Krew는 kubectl 플러그인이기도 합니다.

즉, Krew 설치는 다른 kubectl 플러그인 설치와 거의 동일하게 진행됩니다. 자세한 지침은 다음에서 확인할 수 있습니다. GitHub 페이지.

가장 중요한 Krew 명령은 다음과 같습니다.

# Поиск в списке плагинов
$ kubectl krew search [<query>]
# Посмотреть информацию о плагине
$ kubectl krew info <plugin>
# Установить плагин
$ kubectl krew install <plugin>
# Обновить все плагины до последней версии
$ kubectl krew upgrade
# Посмотреть все плагины, установленные через Krew
$ kubectl krew list
# Деинсталлировать плагин
$ kubectl krew remove <plugin>

Krew를 사용하여 플러그인을 설치하더라도 위에 설명된 표준 방법을 사용하여 플러그인을 설치하는 것과 간섭하지 않습니다.

명령어를 참고해주세요 kubectl krew list Krew를 사용하여 설치된 플러그인만 표시하는 반면 명령은 kubectl plugin list Krew와 함께 설치된 플러그인과 다른 방법으로 설치된 플러그인을 모두 나열합니다.

다른 곳에서 플러그인 검색

Krew는 현재 진행 중인 젊은 프로젝트입니다. 목록 총 30개 정도의 플러그인이 있습니다. 필요한 플러그인을 찾지 못하셨다면 GitHub 등 다른 곳에서 플러그인을 찾아보실 수 있습니다.

GitHub 섹션을 살펴보는 것이 좋습니다. kubectl-플러그인여기에서는 확인할 만한 수십 개의 플러그인을 찾을 수 있습니다.

나만의 플러그인 작성하기

당신은 스스로 할 수 있습니다 플러그인을 생성하다 — 어렵지 않습니다. 원하는 작업을 수행하는 실행 파일을 만들고 이름을 다음과 같이 지정하면 됩니다. kubectl-x 위에 설명한 대로 설치하세요.

파일은 bash 스크립트, python 스크립트 또는 컴파일된 go 애플리케이션일 수 있습니다. 어떤 파일이든 상관없습니다. 유일한 요구 사항은 운영 체제에서 직접 실행될 수 있어야 한다는 것입니다.

지금 바로 예제 플러그인을 만들어 보겠습니다. 이전 섹션에서는 kubectl 명령을 사용하여 각 포드의 컨테이너를 나열했습니다. 이 명령을 다음과 같이 호출할 수 있는 플러그인으로 쉽게 변환할 수 있습니다. kubectl img.

파일 만들기 kubectl-img 다음 내용 :

#!/bin/bash
kubectl get pods -o custom-columns='NAME:metadata.name,IMAGES:spec.containers[*].image'

이제 다음을 사용하여 파일을 실행 가능하게 만드십시오. chmod +x kubectl-img PATH에 있는 디렉토리로 옮기세요. 그 후 바로 플러그인을 사용할 수 있습니다. kubectl img.

앞서 언급했듯이 kubectl 플러그인은 모든 프로그래밍 언어나 스크립팅 언어로 작성할 수 있습니다. 셸 스크립트를 사용하는 경우 플러그인 내에서 kubectl을 쉽게 호출할 수 있다는 장점이 있습니다. 하지만 실제 프로그래밍 언어로 더 복잡한 플러그인을 작성할 수도 있습니다. 쿠버네티스 클라이언트 라이브러리Go를 사용하는 경우 다음도 사용할 수 있습니다. cli-런타임 라이브러리kubectl 플러그인을 작성하기 위해 특별히 만들어진 것입니다.

플러그인을 공유하는 방법

여러분의 플러그인이 다른 사람들에게 유용하다고 생각되시면 GitHub에 공유해 주세요. 해당 주제에도 꼭 추가해 주세요. kubectl-플러그인.

플러그인을 추가하도록 요청할 수도 있습니다. 크루 목록. 이를 수행하는 방법에 대한 지침은 다음과 같습니다. GitHub 저장소.

명령 완료

플러그인은 현재 자동 완성을 지원하지 않으므로 전체 플러그인 이름과 전체 인수 이름을 입력해야 합니다.

GitHub 저장소에 이 기능에 대한 kubectl 저장소가 있습니다. 공개 요청따라서 이 기능이 언젠가는 미래에 구현될 가능성이 있습니다.

행운을 빌어 요 !!!

주제에 대해 더 읽을 내용:

1. Kubernetes의 세 가지 수준의 자동 확장 및 이를 효과적으로 사용하는 방법.
2. 구현을 위한 템플릿을 갖춘 불법 복제 정신의 Kubernetes.
3. Telegram의 Kubernetes 주변 채널.

출처 : habr.com