Kubernetes 확장 및 보완(개요 및 동영상 보고서)

8월 XNUMX일 컨퍼런스에서 세인트 하이로드++ 2019, "DevOps 및 운영" 섹션의 일부로 Flant 회사 직원 XNUMX명이 참여한 "Kubernetes 확장 및 보완" 보고서가 작성되었습니다. 여기에서 우리는 Kubernetes의 기능을 확장하고 보완하고 싶었지만 이미 만들어진 간단한 솔루션을 찾지 못한 수많은 상황에 대해 이야기합니다. 우리는 오픈 소스 프로젝트 형태로 필요한 솔루션을 보유하고 있으며 이 연설도 이에 대한 것입니다.

전통에 따라 우리는 이를 기쁘게 생각합니다. 보고서 영상 (50분, 기사보다 훨씬 더 유익함) 및 텍스트 형식의 주요 요약. 가다!

K8s의 핵심 및 추가 사항

Kubernetes는 업계와 오랫동안 확립된 관리 접근 방식을 변화시키고 있습니다.

• 그 덕분에 추상화, 우리는 더 이상 구성 설정이나 명령(Chef, Ansible...) 실행과 같은 개념으로 작업하지 않고 컨테이너, 서비스 등의 그룹화를 사용합니다.
• 우리는 응용 프로그램의 뉘앙스를 생각하지 않고 응용 프로그램을 준비할 수 있습니다. 특정 사이트, 출시 예정: 베어메탈, 공급자 중 하나의 클라우드 등
• K8을 사용하면 더 쉽게 접근할 수 있습니다. 모범 사례 인프라 구성: 확장 기술, 자가 복구, 내결함성 등

그러나 물론 모든 것이 순조롭게 진행되는 것은 아닙니다. Kubernetes 역시 새로운 과제를 안겨주었습니다.

Kubernetes 아니 모든 사용자의 모든 문제를 해결하는 결합입니다. 핵심 Kubernetes는 다음에 존재하는 최소한의 필수 기능 세트만 담당합니다. 각 무리:

Kubernetes 코어는 컨테이너 그룹화, 트래픽 관리 등을 위한 기본 기본 요소 세트를 정의합니다. 우리는 그들에 대해 더 자세히 이야기했습니다. 2년 전 보고.

반면, K8s는 사용 가능한 기능을 확장하여 다른 기능을 닫는 데 도움이 되는 좋은 기회를 제공합니다. 특정한 — 사용자 요구. Kubernetes에 대한 추가 사항은 [특정 문제를 해결하기 위해] 클러스터를 "올바른 모양"으로 만드는 데 필요한 모든 것을 설치하고 구성해야 하는 클러스터 관리자의 책임입니다. 이것들은 어떤 종류의 추가 사항입니까? 몇 가지 예를 살펴보겠습니다.

추가 기능의 예

Kubernetes를 설치한 후 노드 내부와 노드 간 Pod의 상호 작용에 꼭 필요한 네트워킹이 자체적으로 작동하지 않는다는 사실에 놀랄 수 있습니다. Kubernetes 커널은 필요한 연결을 보장하지 않고 대신 네트워크를 결정합니다. 인터페이스 (CNI) 타사 추가 기능의 경우. 네트워크 구성을 담당하는 추가 기능 중 하나를 설치해야 합니다.

가까운 예로는 데이터 스토리지 솔루션(로컬 디스크, 네트워크 블록 장치, Ceph...)이 있습니다. 처음에는 핵심에 있었지만 출현과 함께 CSI 상황은 이미 설명한 것과 비슷한 것으로 변경됩니다. 인터페이스는 Kubernetes에 있고 해당 구현은 타사 모듈에 있습니다.

다른 예는 다음과 같습니다.

• 입구-컨트롤러 (그들의 리뷰를 참조하세요 우리의 최근 기사).
• 인증 관리자:

  

• 연산자 언급된 인증서 관리자를 포함하는 전체 추가 기능 클래스이며 기본 요소와 컨트롤러를 정의합니다. 그들의 작업 논리는 우리의 상상력에 의해서만 제한되며 기성 인프라 구성 요소(예: DBMS)를 기본 요소로 전환할 수 있으며, 이는 컨테이너 세트 및 해당 설정보다 작업하기가 훨씬 쉽습니다. 수많은 오퍼레이터가 작성되었습니다. 그 중 다수가 아직 생산 준비가 되지 않았더라도 이는 시간 문제일 뿐입니다.

  

• 측정항목 - Kubernetes가 인터페이스(Metrics API)를 구현(Prometheus 어댑터, Datadog 클러스터 에이전트와 같은 타사 추가 기능...)에서 분리하는 방법에 대한 또 다른 그림입니다.
• 에 모니터링 및 통계, 실제로는 필요할 뿐만 아니라 프로메테우스와 그라파나, kube-state-metrics, node-exporter 등도 있습니다.

그리고 이것은 추가 사항의 전체 목록이 아닙니다... 예를 들어, 현재 우리가 설치하고 있는 Flant 회사에는 29개 추가 (모두 총 249개의 Kubernetes 객체를 생성합니다). 간단히 말해서, 추가 없이는 클러스터의 수명을 볼 수 없습니다.

오토메이션

운영자는 우리가 매일 접하는 일상적인 작업을 자동화하도록 설계되었습니다. 연산자를 작성하는 것이 훌륭한 솔루션이 될 수 있는 실제 예는 다음과 같습니다.

1. 애플리케이션 이미지가 포함된 개인(즉, 로그인 필요) 레지스트리가 있습니다. 각 포드에는 레지스트리에서 인증을 허용하는 특수 비밀이 할당된 것으로 가정됩니다. 우리의 임무는 포드가 이미지를 다운로드할 수 있도록 이 비밀이 네임스페이스에서 발견되는지 확인하는 것입니다. 많은 애플리케이션(각각에는 비밀이 필요함)이 있을 수 있으며 비밀 자체를 정기적으로 업데이트하는 것이 유용하므로 수동으로 비밀을 배치하는 옵션이 제거됩니다. 여기서 운영자가 구조에 나섭니다. 네임스페이스가 나타날 때까지 기다리는 컨트롤러를 만들고 이 이벤트를 기반으로 네임스페이스에 비밀을 추가합니다.
2. 기본적으로 포드에서 인터넷으로의 액세스는 금지되어 있습니다. 그러나 때로는 필요할 수도 있습니다. 예를 들어 네임스페이스에 특정 레이블이 있으면 특정 기술이 필요하지 않고 액세스 권한 메커니즘이 간단하게 작동하는 것이 논리적입니다. 여기서 교환원이 우리를 어떻게 도와줄 수 있나요? 레이블이 네임스페이스에 나타날 때까지 기다리고 인터넷 액세스에 대한 적절한 정책을 추가하는 컨트롤러가 생성됩니다.
3. 비슷한 상황: 특정 항목을 추가해야 한다고 가정해 보겠습니다. 더러움, 유사한 라벨(일종의 접두사 포함)이 있는 경우. 운영자와의 행동은 뻔하다...

모든 클러스터에서는 일상적인 작업을 해결해야 하며 바르게 이는 연산자를 사용하여 수행할 수 있습니다.

설명 된 모든 이야기를 요약하면 다음과 같은 결론에 도달했습니다. Kubernetes에서 편안한 작업을 위해 필요한 것: ㅏ) 추가 기능 설치, 비) 운영자를 개발하다 (일상적인 관리 작업을 해결하기 위해)

Kubernetes에 대한 설명을 작성하는 방법은 무엇입니까?

일반적으로 구성표는 간단합니다.

... 그런데 다음과 같은 사실이 밝혀졌습니다.

• Kubernetes API는 숙달하는 데 많은 시간이 걸리는 다소 중요한 기능입니다.
• 프로그래밍도 모든 사람을 위한 것은 아닙니다(Go 언어는 특별한 프레임워크가 있기 때문에 선호하는 언어로 선택되었습니다. 연산자 SDK);
• 상황은 프레임워크 자체와 유사합니다.

하단 라인 : 컨트롤러를 작성하려면 (운영자는) 해야 한다 상당한 자원을 소비하다 재료 공부하기. 이는 "대규모" 운영자, 예를 들어 MySQL DBMS의 경우에 적합합니다. 그러나 위에서 설명한 예(비밀 공개, 인터넷에 대한 포드 액세스...)를 기억하고 올바르게 수행하려는 경우 소비된 노력이 지금 필요한 결과보다 크다는 것을 이해할 것입니다.

일반적으로 딜레마가 발생합니다. 많은 자원을 소비하고 성명서를 작성하는 데 적합한 도구를 찾거나 구식 방식으로(그러나 빠르게) 수행합니다. 이를 해결하기 위해 - 이러한 극단 사이의 절충안을 찾기 위해 - 우리는 자체 프로젝트를 만들었습니다. 쉘 연산자 (또한 그의 최근 발표 허브에서).

쉘 연산자

그는 어떻게 일합니까? 클러스터에는 셸 연산자가 포함된 Go 바이너리가 포함된 Pod가 있습니다. 그 옆에는 세트가 있어요 후크 (자세한 내용은 아래 참조). 쉘 운영자 자체는 특정 항목을 구독합니다. 개발 Kubernetes API에서 발생 시 해당 후크를 시작합니다.

쉘 운영자는 어떤 이벤트에 어떤 후크를 호출할지 어떻게 알 수 있나요? 이 정보는 후크 자체를 통해 쉘 운영자에게 전송되며 매우 간단하게 수행됩니다.

후크는 단일 인수를 허용하는 Bash 스크립트 또는 기타 실행 파일입니다. --config JSON으로 응답합니다. 후자는 관심 있는 개체와 응답해야 하는 이벤트(이러한 개체에 대해)를 결정합니다.

우리 예제 중 하나인 셸 연산자에 대한 구현을 설명하겠습니다. 즉, 애플리케이션 이미지를 사용하여 개인 레지스트리에 액세스하기 위한 비밀을 분해합니다. 두 단계로 구성됩니다.

연습: 1. Hook 작성

우선 Hook에서 처리하겠습니다. --config, 이는 우리가 네임스페이스, 특히 네임스페이스가 생성된 순간에 관심이 있음을 나타냅니다.

[[ $1 == "--config" ]] ; then
  cat << EOF
{
  "onKubernetesEvent": [
    {
      "kind": "namespace",
      "event": ["add"]
    }
  ]
}
EOF
…

논리는 어떤 모습일까요? 또한 매우 간단합니다.

…
else
  createdNamespace=$(jq -r '.[0].resourceName' $BINDING_CONTEXT_PATH)
  kubectl create -n ${createdNamespace} -f - << EOF
Kind: Secret
...
EOF
fi

첫 번째 단계는 어떤 네임스페이스가 생성되었는지 확인하는 것이고, 두 번째 단계는 다음을 사용하여 네임스페이스를 만드는 것입니다. kubectl 이 네임스페이스의 비밀입니다.

연습: 2. 이미지 조립하기

남은 것은 생성된 후크를 쉘 운영자에게 전달하는 것뿐입니다. 이를 수행하는 방법은 무엇입니까? 셸 연산자 자체는 Docker 이미지로 제공되므로 우리의 작업은 이 이미지의 특수 디렉터리에 후크를 추가하는 것입니다.

FROM flant/shell-operator:v1.0.0-beta.1
ADD my-handler.sh /hooks

남은 것은 그것을 조립하고 밀어내는 것뿐입니다.

$ docker build -t registry.example.com/my-operator:v1 .
$ docker push registry.example.com/my-operator:v1

마지막 작업은 이미지를 클러스터에 배포하는 것입니다. 이를 위해 다음과 같이 작성해 보겠습니다. 전개:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: my-operator
spec:
  template:
    spec:
      containers:
      - name: my-operator
        image: registry.example.com/my-operator:v1 # 1
      serviceAccountName: my-operator              # 2

주의해야 할 두 가지 사항이 있습니다.

1. 새로 생성된 이미지 표시;
2. 이는 최소한 Kubernetes의 이벤트를 구독하고 네임스페이스에 비밀을 할당할 수 있는 권한이 필요한 시스템 구성 요소이므로 후크에 대한 ServiceAccount(및 규칙 세트)를 생성합니다.

결과 - 문제를 해결했습니다 친척들에게 비밀을 분해하기 위한 연산자를 생성하는 방식으로 Kubernetes를 위한 것입니다.

기타 쉘 연산자 기능

후크가 작동할 선택한 유형의 개체를 제한하려면, 필터링할 수 있어요, 특정 라벨에 따라 선택(또는 matchExpressions):

"onKubernetesEvent": [
  {
    "selector": {
      "matchLabels": {
        "foo": "bar",
       },
       "matchExpressions": [
         {
           "key": "allow",
           "operation": "In",
           "values": ["wan", "warehouse"],
         },
       ],
     }
     …
  }
]

제공 중복 제거 메커니즘, jq 필터를 사용하면 큰 JSON 개체를 작은 개체로 변환할 수 있으며, 변경 사항을 모니터링하려는 매개변수만 남습니다.

후크가 호출되면 쉘 연산자가 이를 전달합니다. 객체 데이터, 어떤 필요에도 사용할 수 있습니다.

후크를 트리거하는 이벤트는 Kubernetes 이벤트로 제한되지 않습니다. 셸 운영자는 다음을 지원합니다. 시간에 따라 후크 호출 (기존 스케줄러의 crontab과 유사) 및 특별 이벤트 시작에. 이러한 모든 이벤트는 결합되어 동일한 후크에 할당될 수 있습니다.

그리고 쉘 연산자의 두 가지 추가 기능은 다음과 같습니다.

1. 효과가있다 비동기적으로. Kubernetes 이벤트(예: 생성되는 객체)가 수신되었으므로 다른 이벤트(예: 삭제되는 동일한 객체)가 클러스터에서 발생할 수 있으며 후크는 이를 설명해야 합니다. 후크가 오류와 함께 실행된 경우 기본적으로 다음과 같습니다. 상기하다 성공적으로 완료될 때까지(이 동작은 변경될 수 있음)
2. 수출한다 측정항목 셸 연산자가 작동하는지 확인할 수 있는 Prometheus의 경우 각 후크에 대한 오류 수와 현재 대기열 크기를 알아보세요.

보고서의 이 부분을 요약하면 다음과 같습니다.

추가 기능 설치

쿠버네티스로 편안한 작업을 위해서는 애드온 설치가 필요하다는 점도 언급됐다. 지금 우리 회사가 걸어온 길을 예로 들어 말씀드리겠습니다.

우리는 여러 클러스터를 사용하여 Kubernetes 작업을 시작했으며 여기에 추가된 것은 Ingress뿐이었습니다. 클러스터마다 다르게 설치해야 했고, 베어메탈, AWS 등 다양한 환경에 맞게 여러 YAML 구성을 만들었습니다.

클러스터가 많을수록 구성도 많아졌습니다. 또한 우리는 이러한 구성 자체를 개선했으며 그 결과 상당히 이질적이 되었습니다.

모든 것을 정리하기 위해 우리는 스크립트(install-ingress.sh)는 배포할 클러스터 유형을 인수로 사용하여 필요한 YAML 구성을 생성하고 이를 Kubernetes에 출시했습니다.

요컨대, 우리의 추가 경로와 그와 관련된 추론은 다음과 같습니다.

• YAML 구성으로 작업하려면 템플릿 엔진이 필요합니다(첫 번째 단계에서는 간단한 sed입니다).
• 클러스터 수가 증가함에 따라 자동 업데이트의 필요성이 생겼습니다(가장 초기 솔루션은 스크립트를 Git에 넣고 cron을 사용하여 업데이트하고 실행하는 것이었습니다).
• Prometheus에도 유사한 스크립트가 필요했습니다(install-prometheus.sh) 그러나 훨씬 더 많은 입력 데이터와 저장 공간(좋은 방법으로 중앙 집중식 및 클러스터)이 필요하고 일부 데이터(비밀번호)가 자동으로 생성될 수 있다는 사실이 주목할 만합니다.

  

• 점점 더 많은 수의 클러스터에 잘못된 것을 배포할 위험이 지속적으로 커지고 있으므로 설치 관리자가 (즉, 두 개의 스크립트: Ingress 및 Prometheus용) 준비가 필요했습니다(Git의 여러 분기, 해당 클러스터에서 업데이트하기 위한 여러 크론: 안정 또는 테스트 클러스터).
• с kubectl apply 선언적이지 않고 객체를 생성할 수만 있고 상태에 대한 결정을 내리거나 삭제할 수 없기 때문에 작업하기가 어려워졌습니다.
• 당시 전혀 구현하지 않았던 일부 기능이 누락되었습니다.
  • 클러스터 업데이트 결과에 대한 완전한 제어,
  • 클러스터(검색)에서 얻을 수 있는 데이터를 기반으로 일부 매개변수(설치 스크립트에 대한 입력) 자동 결정,
  • 지속적인 발견의 형태로 논리적 발전을 이룬다.

우리는 이 모든 축적된 경험을 다른 프로젝트의 틀 내에서 구현했습니다. 애드온 연산자.

애드온 운영자

이는 이미 언급된 쉘 연산자를 기반으로 합니다. 전체 시스템은 다음과 같습니다.

쉘 연산자 후크에 다음이 추가되었습니다.

• 가치 저장,
• 투구 차트,
• 구성 요소 가치 저장을 모니터링합니다. 그리고 - 변경 사항이 있는 경우 - Helm에게 차트를 다시 롤링하도록 요청합니다.

따라서 Kubernetes의 이벤트에 반응하고 후크를 실행할 수 있으며 이 후크에서 스토리지를 변경할 수 있으며 그 후에 차트가 다시 다운로드됩니다. 결과 다이어그램에서는 후크 세트와 차트를 하나의 구성 요소로 분리합니다. 기준 치수:

많은 모듈이 있을 수 있으며 여기에 글로벌 후크, 글로벌 값 저장소 및 이 글로벌 저장소를 모니터링하는 구성 요소를 추가합니다.

이제 Kubernetes에서 어떤 일이 발생하면 글로벌 후크를 사용하여 이에 반응하고 글로벌 저장소에서 무언가를 변경할 수 있습니다. 이 변경 사항이 감지되어 클러스터의 모든 모듈이 롤아웃됩니다.

이 구성표는 위에 명시된 추가 기능 설치에 대한 모든 요구 사항을 충족합니다.

• Helm은 템플릿 작성 및 선언성을 담당합니다.
• 자동 업데이트 문제는 일정에 따라 레지스트리로 이동하여 새 시스템 이미지가 발견되면 이를 롤아웃(예: "자체")하는 글로벌 후크를 사용하여 해결되었습니다.
• 클러스터에 설정을 저장하는 것은 다음을 사용하여 구현됩니다. 컨피그맵, 저장소의 기본 데이터가 포함되어 있습니다(시작 시 저장소에 로드됨).
• 비밀번호 생성, 검색 및 지속적인 검색과 관련된 문제는 후크를 사용하여 해결되었습니다.
• Docker가 기본적으로 지원하는 태그 덕분에 스테이징이 달성됩니다.
• 결과는 상태를 이해할 수 있는 측정항목을 사용하여 모니터링됩니다.

이 전체 시스템은 Go에서 addon-operator라고 불리는 단일 바이너리 형태로 구현됩니다. 이렇게 하면 다이어그램이 더 단순해 보입니다.

이 다이어그램의 주요 구성요소는 모듈 세트입니다. (아래 회색으로 강조 표시). 이제 약간의 노력으로 필요한 추가 기능에 대한 모듈을 작성할 수 있으며 해당 모듈이 각 클러스터에 설치되고 업데이트되며 클러스터에 필요한 이벤트에 응답하는지 확인할 수 있습니다.

"플랜트"는 애드온 연산자 70개 이상의 Kubernetes 클러스터에서. 현재 상태 - 알파 버전. 이제 베타 출시를 위한 문서를 준비하고 있지만 현재는 저장소에 있습니다. 사용 가능한 예, 이를 기반으로 자신만의 애드온을 만들 수 있습니다.

addon-operator 모듈은 어디서 구할 수 있나요? 우리 도서관 출판은 우리의 다음 단계이며 여름에 출판할 계획입니다.

비디오 및 슬라이드

공연 영상(~50분):

보고서 발표:

PS

우리 블로그의 다른 보고서:

• «데이터베이스와 Kubernetes"; (Dmitry Stolyarov; HighLoad++에서 8년 2018월 XNUMX일);
• «모니터링 및 Kubernetes"; (Dmitry Stolyarov; 28년 2018월 XNUMX일 RootConf에서);
• «Kubernetes 및 GitLab을 사용한 CI/CD 모범 사례"; (Dmitry Stolyarov; HighLoad++에서 7년 2017월 XNUMX일);
• «소규모 프로젝트에서의 Kubernetes 경험"; (Dmitry Stolyarov; 6년 2017월 XNUMX일 RootConf에서).

다음 출판물에도 관심이 있으실 것입니다.

• «Shell-Operator 소개: Kubernetes용 연산자 생성이 더욱 쉬워졌습니다.".

출처 : habr.com