가다? 세게 때리다! 쉘 오퍼레이터를 만나보세요(KubeCon EU'2020의 리뷰 및 비디오 보고서)

올해 유럽의 주요 Kubernetes 컨퍼런스인 KubeCon + CloudNativeCon Europe 2020은 가상으로 개최되었습니다. 그러나 이러한 형식 변경으로 인해 우리가 오랫동안 계획한 보고서 "Go?"를 전달하는 데 방해가 되지는 않았습니다. 세게 때리다! 오픈소스 프로젝트 전용 Shell-operator를 만나보세요” 쉘 연산자.

강연에서 영감을 받아 작성된 이 기사에서는 Kubernetes용 연산자 생성 프로세스를 단순화하는 접근 방식을 제시하고 셸 연산자를 사용하여 최소한의 노력으로 자신만의 연산자를 만드는 방법을 보여줍니다.

소개 보고서 영상 (영어로 최대 23분, 기사보다 훨씬 더 많은 정보 제공) 및 텍스트 형식의 주요 발췌문입니다. 가다!

Flant에서는 지속적으로 모든 것을 최적화하고 자동화합니다. 오늘 우리는 또 다른 흥미로운 개념에 대해 이야기하겠습니다. 만나다: 클라우드 네이티브 셸 스크립팅!

하지만 이 모든 일이 일어나는 맥락인 Kubernetes부터 시작해 보겠습니다.

Kubernetes API 및 컨트롤러

Kubernetes의 API는 각 개체 유형에 대한 디렉터리가 있는 일종의 파일 서버로 표현될 수 있습니다. 이 서버의 개체(리소스)는 YAML 파일로 표시됩니다. 또한 서버에는 다음 세 가지 작업을 수행할 수 있는 기본 API가 있습니다.

• ~을 받다 종류와 이름에 따른 자원;
• 변화 리소스(이 경우 서버는 "올바른" 개체만 저장합니다. 잘못 구성된 개체나 다른 디렉터리용 개체는 모두 삭제됩니다.)
• 따르다 리소스에 대한 것입니다(이 경우 사용자는 즉시 현재/업데이트된 버전을 받습니다).

따라서 Kubernetes는 세 가지 기본 방법을 사용하여 일종의 파일 서버(YAML 매니페스트용) 역할을 합니다(예, 실제로 다른 방법도 있지만 지금은 생략하겠습니다).

문제는 서버가 정보만 저장할 수 있다는 것입니다. 그것이 작동하도록하려면 다음이 필요합니다. 제어 장치 - Kubernetes 세계에서 두 번째로 중요하고 기본적인 개념입니다.

컨트롤러에는 두 가지 주요 유형이 있습니다. 첫 번째는 Kubernetes에서 정보를 가져와 중첩된 논리에 따라 처리한 후 K8s에 반환합니다. 두 번째 유형은 Kubernetes에서 정보를 가져오지만 첫 번째 유형과 달리 일부 외부 리소스의 상태를 변경합니다.

Kubernetes에서 배포를 생성하는 프로세스를 자세히 살펴보겠습니다.

• 배포 컨트롤러(포함됨 kube-controller-manager)은 배포에 대한 정보를 수신하고 ReplicaSet을 생성합니다.
• ReplicaSet은 이 정보를 기반으로 두 개의 복제본(두 개의 Pod)을 생성하지만 이러한 Pod는 아직 예약되지 않았습니다.
• 스케줄러는 포드를 예약하고 해당 YAML에 노드 정보를 추가합니다.
• Kubelet은 외부 리소스(예: Docker)를 변경합니다.

그런 다음 이 전체 시퀀스가 ​​역순으로 반복됩니다. kubelet은 컨테이너를 확인하고 포드의 상태를 계산한 후 다시 보냅니다. ReplicaSet 컨트롤러는 상태를 수신하고 복제본 세트의 상태를 업데이트합니다. 배포 컨트롤러에서도 동일한 일이 발생하며 사용자는 최종적으로 업데이트된(현재) 상태를 얻습니다.

쉘 연산자

Kubernetes는 다양한 컨트롤러의 공동 작업을 기반으로 하는 것으로 나타났습니다(Kubernetes 운영자도 컨트롤러입니다). 최소한의 노력으로 자신만의 연산자를 만드는 방법에 대한 질문이 생깁니다. 그리고 우리가 개발한 것이 구출되었습니다. 쉘 연산자. 이를 통해 시스템 관리자는 익숙한 방법을 사용하여 자신만의 명령문을 작성할 수 있습니다.

간단한 예: 비밀 복사

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

Kubernetes 클러스터가 있다고 가정해 보겠습니다. 네임스페이스가 있습니다. default 비밀이 있는 mysecret. 또한 클러스터에는 다른 네임스페이스도 있습니다. 그들 중 일부에는 특정 라벨이 부착되어 있습니다. 우리의 목표는 Secret을 라벨이 있는 네임스페이스에 복사하는 것입니다.

새 네임스페이스가 클러스터에 나타날 수 있고 그 중 일부에 이 레이블이 있을 수 있다는 사실로 인해 작업이 복잡해집니다. 반면, 라벨이 삭제되면 Secret도 함께 삭제되어야 합니다. 이 외에도 비밀 자체도 변경될 수 있습니다. 이 경우 새 비밀은 라벨이 있는 모든 네임스페이스에 복사되어야 합니다. 네임스페이스에서 Secret이 실수로 삭제된 경우 운영자는 즉시 이를 복원해야 합니다.

이제 작업이 공식화되었으므로 셸 연산자를 사용하여 구현을 시작할 차례입니다. 하지만 먼저 쉘 오퍼레이터 자체에 대해 몇 마디 말할 가치가 있습니다.

쉘 오퍼레이터의 작동 방식

Kubernetes의 다른 워크로드와 마찬가지로 Shell-Operator는 자체 포드에서 실행됩니다. 디렉터리의 이 포드에서 /hooks 실행 파일이 저장됩니다. Bash, Python, Ruby 등의 스크립트일 수 있습니다. 우리는 이러한 실행 파일을 후크(hook)라고 부릅니다.후크).

Shell-operator는 Kubernetes 이벤트를 구독하고 필요한 이벤트에 대한 응답으로 이러한 후크를 실행합니다.

쉘 운영자는 어떤 후크를 언제 실행할지 어떻게 알 수 있나요? 요점은 모든 후크에는 두 단계가 있다는 것입니다. 시작하는 동안 쉘 운영자는 인수를 사용하여 모든 후크를 실행합니다. --config 구성 단계입니다. 그 후에 후크는 연결된 이벤트에 대한 응답으로 일반적인 방식으로 실행됩니다. 후자의 경우 후크는 바인딩 컨텍스트(바인딩 컨텍스트) - JSON 형식의 데이터입니다. 이에 대해서는 아래에서 자세히 설명하겠습니다.

Bash에서 연산자 만들기

이제 구현 준비가 되었습니다. 이를 위해서는 두 가지 함수를 작성해야 합니다(그런데 우리는 다음을 권장합니다). 도서관 shell_lib, 이는 Bash에서 후크 작성을 크게 단순화합니다):

• 첫 번째는 구성 단계에 필요합니다. 바인딩 컨텍스트를 표시합니다.
• 두 번째에는 후크의 주요 논리가 포함되어 있습니다.

#!/bin/bash

source /shell_lib.sh

function __config__() {
  cat << EOF
    configVersion: v1
    # BINDING CONFIGURATION
EOF
}

function __main__() {
  # THE LOGIC
}

hook::run "$@"

다음 단계는 어떤 객체가 필요한지 결정하는 것입니다. 우리의 경우에는 다음을 추적해야 합니다.

• 변경을 위한 소스 비밀;
• 클러스터의 모든 네임스페이스를 통해 어떤 네임스페이스에 레이블이 붙어 있는지 알 수 있습니다.
• 대상 비밀이 모두 소스 비밀과 동기화되어 있는지 확인하세요.

비밀 소스를 구독하세요

이에 대한 바인딩 구성은 매우 간단합니다. 우리는 이름으로 Secret에 관심이 있음을 나타냅니다. mysecret 네임스페이스에서 default:

function __config__() {
  cat << EOF
    configVersion: v1
    kubernetes:
    - name: src_secret
      apiVersion: v1
      kind: Secret
      nameSelector:
        matchNames:
        - mysecret
      namespace:
        nameSelector:
          matchNames: ["default"]
      group: main
EOF

결과적으로 소스 비밀이 변경되면 후크가 트리거됩니다(src_secret) 다음 바인딩 컨텍스트를 수신합니다.

보시다시피 이름과 전체 개체가 포함되어 있습니다.

네임스페이스 추적

이제 네임스페이스를 구독해야 합니다. 이를 위해 다음 바인딩 구성을 지정합니다.

- name: namespaces
  group: main
  apiVersion: v1
  kind: Namespace
  jqFilter: |
    {
      namespace: .metadata.name,
      hasLabel: (
       .metadata.labels // {} |  
         contains({"secret": "yes"})
      )
    }
  group: main
  keepFullObjectsInMemory: false

보시다시피, 이름이 다음과 같은 새 필드가 구성에 나타났습니다. jqFilter. 이름에서 알 수 있듯이, jqFilter 불필요한 정보를 모두 필터링하고 관심 있는 필드가 포함된 새 JSON 개체를 만듭니다. 유사한 구성을 가진 후크는 다음 바인딩 컨텍스트를 수신합니다.

배열이 포함되어 있습니다. filterResults 클러스터의 각 네임스페이스에 대해. 부울 변수 hasLabel 지정된 네임스페이스에 레이블이 연결되어 있는지 여부를 나타냅니다. 선택자 keepFullObjectsInMemory: false 완전한 객체를 메모리에 보관할 필요가 없음을 나타냅니다.

대상 비밀 추적

주석이 지정된 모든 비밀을 구독합니다. managed-secret: "yes" (이게 우리 목표야 dst_secrets):

- name: dst_secrets
  apiVersion: v1
  kind: Secret
  labelSelector:
    matchLabels:
      managed-secret: "yes"
  jqFilter: |
    {
      "namespace":
        .metadata.namespace,
      "resourceVersion":
        .metadata.annotations.resourceVersion
    }
  group: main
  keepFullObjectsInMemory: false

이 경우 jqFilter 네임스페이스와 매개변수를 제외한 모든 정보를 필터링합니다. resourceVersion. 비밀을 생성할 때 마지막 매개변수가 주석에 전달되었습니다. 이를 통해 비밀의 버전을 비교하고 최신 상태로 유지할 수 있습니다.

이러한 방식으로 구성된 후크는 실행 시 위에서 설명한 세 가지 바인딩 컨텍스트를 수신합니다. 일종의 스냅샷(스냅 사진) 무리.

이 모든 정보를 바탕으로 기본 알고리즘을 개발할 수 있습니다. 모든 네임스페이스를 반복하고 다음을 수행합니다.

• 면 hasLabel 문제 true 현재 네임스페이스의 경우:
  • 전역 비밀을 로컬 비밀과 비교합니다.
    • 동일하다면 아무 일도 일어나지 않습니다.
    • 서로 다른 경우 - 실행 kubectl replace 또는 create;
• 면 hasLabel 문제 false 현재 네임스페이스의 경우:
  • Secret이 지정된 네임스페이스에 없는지 확인하세요.
    • 로컬 비밀이 있으면 다음을 사용하여 삭제하세요. kubectl delete;
    • 로컬 비밀이 감지되지 않으면 아무 작업도 수행하지 않습니다.

Bash에서 알고리즘 구현 우리에서 다운로드할 수 있습니다 예제가 있는 저장소.

이것이 바로 우리가 35줄의 YAML 구성과 거의 동일한 양의 Bash 코드를 사용하여 간단한 Kubernetes 컨트롤러를 생성할 수 있었던 방법입니다! 쉘 운영자의 임무는 이들을 서로 연결하는 것입니다.

그러나 비밀 복사가 유틸리티 적용의 유일한 영역은 아닙니다. 그가 무엇을 할 수 있는지 보여주는 몇 가지 예가 더 있습니다.

예시 1: ConfigMap 변경

세 개의 포드로 구성된 배포를 살펴보겠습니다. 포드는 ConfigMap을 사용하여 일부 구성을 저장합니다. 포드가 시작되었을 때 ConfigMap은 특정 상태에 있었습니다(v.1이라고 하겠습니다). 따라서 모든 Pod는 이 특정 버전의 ConfigMap을 사용합니다.

이제 ConfigMap이 변경되었다고 가정해 보겠습니다(v.2). 그러나 Pod는 이전 버전의 ConfigMap(v.1)을 사용합니다.

새로운 ConfigMap(v.2)으로 전환하려면 어떻게 해야 합니까? 대답은 간단합니다. 템플릿을 사용하세요. 섹션에 체크섬 주석을 추가해 보겠습니다. template 배포 구성:

결과적으로 이 체크섬은 모든 Pod에 등록되며, 배포의 체크섬과 동일하게 됩니다. 이제 ConfigMap이 변경될 때 주석을 업데이트하기만 하면 됩니다. 이 경우 쉘 연산자가 유용합니다. 프로그램만 하면 된다 ConfigMap을 구독하고 체크섬을 업데이트하는 후크.

사용자가 ConfigMap을 변경하면 쉘 운영자는 이를 인지하고 체크섬을 다시 계산합니다. 그 후에 Kubernetes의 마법이 발휘됩니다. 오케스트레이터는 포드를 종료하고 새 포드를 생성한 후 포드가 활성화될 때까지 기다립니다. Ready, 그리고 다음으로 넘어갑니다. 결과적으로 배포는 ConfigMap의 새 버전을 동기화하고 전환합니다.

예 2: 사용자 정의 리소스 정의 작업

아시다시피 Kubernetes를 사용하면 사용자 정의 유형의 객체를 생성할 수 있습니다. 예를 들어 종류를 만들 수 있습니다. MysqlDatabase. 이 유형에 두 개의 메타데이터 매개변수가 있다고 가정해 보겠습니다. name и namespace.

apiVersion: example.com/v1alpha1
kind: MysqlDatabase
metadata:
  name: foo
  namespace: bar

MySQL 데이터베이스를 생성할 수 있는 다양한 네임스페이스를 가진 Kubernetes 클러스터가 있습니다. 이 경우 쉘 연산자를 사용하여 리소스를 추적할 수 있습니다. MysqlDatabase, 이를 MySQL 서버에 연결하고 클러스터의 원하는 상태와 관찰된 상태를 동기화합니다.

예 3: 클러스터 네트워크 모니터링

아시다시피 ping을 사용하는 것은 네트워크를 모니터링하는 가장 간단한 방법입니다. 이 예에서는 shell-operator를 사용하여 이러한 모니터링을 구현하는 방법을 보여줍니다.

우선, 노드를 구독해야 합니다. 쉘 운영자는 각 노드의 이름과 IP 주소가 필요합니다. 도움을 받아 그는 이러한 노드에 핑을 보낼 것입니다.

configVersion: v1
kubernetes:
- name: nodes
  apiVersion: v1
  kind: Node
  jqFilter: |
    {
      name: .metadata.name,
      ip: (
       .status.addresses[] |  
        select(.type == "InternalIP") |
        .address
      )
    }
  group: main
  keepFullObjectsInMemory: false
  executeHookOnEvent: []
schedule:
- name: every_minute
  group: main
  crontab: "* * * * *"

매개 변수 executeHookOnEvent: [] 이벤트에 대한 응답(즉, 노드 변경, 추가, 삭제에 대한 응답)으로 후크가 실행되는 것을 방지합니다. 그러나 그는 달릴 것이다 (그리고 노드 목록을 업데이트합니다) 예정대로 - 현장에서 규정한 대로 XNUMX분마다 schedule.

이제 질문이 생깁니다. 패킷 손실과 같은 문제를 정확히 어떻게 알 수 있습니까? 코드를 살펴보겠습니다.

function __main__() {
  for i in $(seq 0 "$(context::jq -r '(.snapshots.nodes | length) - 1')"); do
    node_name="$(context::jq -r '.snapshots.nodes['"$i"'].filterResult.name')"
    node_ip="$(context::jq -r '.snapshots.nodes['"$i"'].filterResult.ip')"
    packets_lost=0
    if ! ping -c 1 "$node_ip" -t 1 ; then
      packets_lost=1
    fi
    cat >> "$METRICS_PATH" <<END
      {
        "name": "node_packets_lost",
        "add": $packets_lost,
        "labels": {
          "node": "$node_name"
        }
      }
END
  done
}

우리는 노드 목록을 반복하고, 노드의 이름과 IP 주소를 얻은 후, 핑을 보내고 결과를 Prometheus로 보냅니다. Shell-operator는 메트릭을 Prometheus로 내보낼 수 있습니다., 환경 변수에 지정된 경로에 따라 위치한 파일에 저장합니다. $METRICS_PATH.

여기 그렇게 클러스터에서 간단한 네트워크 모니터링을 위한 운영자를 만들 수 있습니다.

대기열 메커니즘

이 기사는 쉘 오퍼레이터에 내장된 또 다른 중요한 메커니즘을 설명하지 않으면 불완전할 것입니다. 클러스터의 이벤트에 대한 응답으로 일종의 후크를 실행한다고 상상해 보세요.

• 동시에 클러스터에 어떤 일이 발생하면 어떻게 될까요? 하나 더 이벤트?
• 쉘 운영자가 후크의 다른 인스턴스를 실행합니까?
• 예를 들어 클러스터에서 동시에 XNUMX개의 이벤트가 발생한다면 어떻게 될까요?
• 쉘 운영자가 이를 병렬로 처리합니까?
• 메모리, CPU 등 소비되는 리소스는 어떻게 되나요?

다행스럽게도 shell-operator에는 대기열 메커니즘이 내장되어 있습니다. 모든 이벤트는 대기열에 추가되어 순차적으로 처리됩니다.

예를 들어 이를 설명해 보겠습니다. 두 개의 후크가 있다고 가정 해 봅시다. 첫 번째 이벤트는 첫 번째 후크로 이동합니다. 처리가 완료되면 대기열이 앞으로 이동합니다. 다음 세 개의 이벤트는 두 번째 후크로 리디렉션됩니다. 대기열에서 제거되어 "번들"에 입력됩니다. 그건 후크는 일련의 이벤트를 수신합니다. — 또는 더 정확하게는 바인딩 컨텍스트의 배열입니다.

또한 이들 이벤트는 하나의 큰 이벤트로 결합될 수 있습니다.. 매개변수가 이를 담당합니다. group 바인딩 구성에서.

원하는 만큼의 대기열/후크와 다양한 조합을 생성할 수 있습니다. 예를 들어 하나의 대기열이 두 개의 후크와 작동할 수 있으며 그 반대의 경우도 마찬가지입니다.

그에 따라 필드를 구성하기만 하면 됩니다. queue 바인딩 구성에서. 큐 이름을 지정하지 않으면 후크는 기본 큐(default). 이 큐잉 메커니즘을 사용하면 후크 작업 시 모든 리소스 관리 문제를 완전히 해결할 수 있습니다.

결론

우리는 셸 연산자가 무엇인지 설명하고, 이를 사용하여 빠르고 쉽게 Kubernetes 연산자를 생성하는 방법을 보여주고, 그 사용에 대한 몇 가지 예를 제시했습니다.

쉘 연산자에 대한 자세한 정보와 사용 방법에 대한 빠른 튜토리얼은 해당 항목에서 확인할 수 있습니다. GitHub의 리포지토리. 궁금한 점이 있으면 주저하지 말고 문의해 주세요. 특별 상담을 통해 해당 문제에 대해 논의할 수 있습니다. 전보 그룹 (러시아어) 또는 이 포럼 (영어로).

마음에 드셨다면 GitHub에서 새로운 이슈/홍보/스타를 만나보실 수 있어 기쁩니다. 그런데 다른 게시물도 찾아보실 수 있습니다. 흥미로운 프로젝트. 그 중에서도 강조할만한 가치가 있습니다 애드온 연산자, 이는 Shell-Operator의 큰 형입니다.. 이 유틸리티는 Helm 차트를 사용하여 추가 기능을 설치하고, 업데이트를 제공하고 다양한 차트 매개변수/값을 모니터링하고, 차트 설치 프로세스를 제어하고, 클러스터의 이벤트에 대한 응답으로 차트를 수정할 수도 있습니다.

비디오 및 슬라이드

공연 영상(~23분):

보고서 발표:

PS

블로그에서도 읽어보세요.

• «Shell-Operator를 사용하여 Kubernetes 연산자를 쉽게 생성: 연간 프로젝트 진행";
• «Shell-Operator 소개: Kubernetes용 연산자 생성이 더욱 쉬워졌습니다.";
• «Kubernetes 클러스터를 준비하는 것이 쉽고 편리합니까? 애드온 운영자 발표";
• «Kubernetes 확장 및 보완"(리뷰 및 영상 보고).

출처 : habr.com