Kubernetes 적용, 교체 및 패치의 적절한 비교

Kubernetes에는 적용, 편집, 패치, 교체 등 리소스 업데이트를 위한 여러 옵션이 있습니다. 각각의 기능과 사용 시기가 혼동됩니다. 그것을 알아 봅시다.

면 구글에서 검색해 보세요 "kubernetes 적용 대 교체"라는 문구가 있습니다. StackOverflow에 답장하다, 이는 정확하지 않습니다. 검색할 때 "kubernetes 적용 대 패치" 첫 번째 링크는 다음에 대한 문서입니다. kubectl patch, 비교는 포함되지 않습니다. apply и patch. 이 기사에서는 다양한 옵션과 각 옵션의 올바른 사용법을 살펴보겠습니다.

Kubernetes 리소스(서비스, 배포, 수신 등)의 수명 주기 동안 때때로 이 리소스의 일부 속성을 변경, 추가 또는 제거해야 합니다. 예를 들어 메모를 추가하고 복제본 수를 늘리거나 줄입니다.

쿠버네티스 CLI

이미 CLI를 통해 Kubernetes 클러스터로 작업하고 있다면 다음 사항에 이미 익숙할 것입니다. apply и edit. 팀 apply 파일에서 리소스 사양을 읽고 Kubernetes 클러스터에 "upsert"를 수행합니다. 즉, 리소스가 없으면 생성하고, 있으면 업데이트합니다. 팀 edit API를 통해 리소스를 읽은 다음 리소스 사양을 로컬 파일에 기록한 다음 텍스트 편집기에서 엽니다. 파일을 편집하고 저장한 후 kubectl API를 통해 변경 사항을 다시 보내면 이러한 변경 사항을 리소스에 신중하게 적용합니다.

모두가 명령을 아는 것은 아닙니다 patch и replace. 팀 patch 명령줄에서 변경된 부분만 제공하여 리소스 사양의 일부를 변경할 수 있습니다. 팀 replace 와 동일하게 작동 edit, 그러나 모든 작업은 수동으로 수행해야 합니다. 예를 들어 다음을 사용하여 리소스 사양의 현재 버전을 다운로드해야 합니다. kubectl get -o yaml, 편집한 다음 사용하세요. replace 변경된 사양에 따라 리소스를 업데이트합니다. 팀 replace 리소스를 읽고 교체하는 사이에 변경 사항이 발생한 경우 작동하지 않습니다.

쿠버네티스 API

아마도 당신은 방법에 익숙할 것입니다. CoreV1().Pods().Update(), replaceNamespacedService 또는 patch_namespaced_deployment, 다음을 통해 클러스터로 작업하는 경우 Kubernetes API용 클라이언트 라이브러리 일부 프로그래밍 언어를 사용합니다. 라이브러리는 메소드를 사용하여 HTTP 요청을 통해 이러한 메소드를 처리합니다. PUT и PATCH. 이 경우, update и replace 사용하다 PUT과 patch, 아무리 사소한 것이라도 다음을 사용합니다. PATCH.

그것은 언급되어야 kubectl API를 통해 클러스터에서도 작동합니다. 다시 말해서, kubectlGo 언어용 클라이언트 라이브러리 위에 있는 래퍼로, 표준 API 기능 외에도 더 간결하고 읽기 쉬운 형식으로 하위 명령을 제공하는 기능을 주로 제공합니다. 예를 들어, 이미 알아차렸을 수도 있지만 다음 메서드는 apply 이전 단락에서는 위에서 언급하지 않았습니다. 현재(2020년 XNUMX월, 약. 역자) 모든 논리 kubectl apply, 즉. 존재하지 않는 리소스를 생성하고 기존 리소스를 업데이트하는 것은 전적으로 코드 측에서 작동합니다. kubectl. 노력을 기울이고 있습니다 논리 전송에 apply API 측에 있지만 아직 베타 버전입니다. 아래에 더 자세히 작성하겠습니다.

기본적으로 패치

가장 잘 사용됨 patch, 리소스를 업데이트하려는 경우. 이는 두 클라이언트 라이브러리가 Kubernetes API를 기반으로 작동하는 방식이며 kubectl (클라이언트 라이브러리의 래퍼이기 때문에 놀랍지도 않습니다. 약. 역자).

전략적으로 작업

모든 팀 kubectl apply, edit и patch 방법을 사용하다 PATCH 기존 리소스를 업데이트하기 위한 HTTP 요청에서. 명령 구현을 더 자세히 살펴보면 모든 명령이 다음 접근 방식을 사용합니다. 전략적 병합 패치 리소스를 업데이트하려면 명령을 실행해야 하지만 patch 다른 접근법을 사용할 수도 있습니다(자세한 내용은 아래 참조). 전략적 병합 패치 접근 방식은 제공된 사양을 기존 사양과 병합하여 "제대로" 시도합니다. 보다 구체적으로 말하면 객체와 배열을 모두 결합하려고 시도하는데, 이는 변경 사항이 추가되는 경향이 있음을 의미합니다. 예를 들어 다음 명령을 실행합니다. patch 포드 컨테이너 사양에 새 환경 변수를 사용하면 해당 환경 변수를 덮어쓰는 대신 기존 환경 변수에 추가됩니다. 이 접근 방식을 사용하여 제거하려면 제공된 사양에서 매개변수 값을 강제로 null로 설정해야 합니다. 어느 팀이 kubectl 업데이트용으로 사용하는 것이 가장 좋나요?

다음을 사용하여 리소스를 생성하고 관리하는 경우 kubectl apply, 업데이트할 때 항상 사용하는 것이 좋습니다 kubectl apply에 kubectl 구성을 관리하고 애플리케이션 간에 요청된 변경 사항을 적절하게 추적할 수 있습니다. 장점은 항상 사용 apply 이는 이전에 적용된 사양을 추적하여 사양 속성과 배열 요소가 명시적으로 제거되는 시기를 알 수 있다는 것입니다. 이를 통해 다음을 사용할 수 있습니다. apply 속성과 배열 요소를 제거하는 반면 일반적인 전략적 병합은 작동하지 않습니다. 팀 edit и patch 다음과 같은 메모를 업데이트하지 마세요. kubectl apply 변경 사항을 추적하는 데 사용되므로 Kubernetes API를 통해 추적 및 수행되지만 명령을 통해 수행된 모든 변경 사항 edit и patch, 후속 명령에는 표시되지 않음 apply즉, apply 에 대한 입력 사양에 나타나지 않더라도 제거하지 않습니다. apply (문서에는 다음과 같이 나와 있습니다. edit и patch 사용된 메모를 업데이트합니다. apply, 그러나 실제로는 - 아니오).

명령을 사용하지 않는 경우 apply, 다음과 같이 사용할 수 있습니다. edit과 patch, 변경 내용에 가장 적합한 명령을 선택합니다. BOM 속성을 추가하고 변경할 때 두 가지 접근 방식은 거의 동일합니다. 사양 속성이나 배열 요소를 삭제하는 경우 edit 일회성 실행처럼 동작합니다. apply, 편집 전후의 사양 추적을 포함하여 리소스에서 속성과 배열 요소를 명시적으로 제거할 수 있습니다. 사양에서 속성 값을 명시적으로 null로 설정해야 합니다. patch리소스에서 제거합니다. 전략적 병합 패치를 사용하여 배열 요소를 제거하는 것은 병합 지시문을 사용해야 하기 때문에 더 복잡합니다. 보다 실행 가능한 대안은 아래의 다른 업그레이드 접근 방식을 참조하세요.

위의 명령과 유사하게 작동하는 업데이트 메서드를 클라이언트 라이브러리에 구현하려면 kubectl, 요청에 설정되어야 합니다. content-type в application/strategic-merge-patch+json. 사양에서 속성을 제거하려면 비슷한 방식으로 해당 값을 명시적으로 null로 설정해야 합니다. kubectl patch. 배열 요소를 제거해야 하는 경우 업데이트 사양에 병합 지시문을 포함하거나 업데이트에 대해 다른 접근 방식을 사용해야 합니다.

업데이트에 대한 다른 접근 방식

Kubernetes는 두 가지 다른 업데이트 접근 방식을 지원합니다. JSON 병합 패치 и JSON 패치. JSON 병합 패치 접근 방식은 부분적인 Kubernetes 사양을 입력으로 사용하고 전략적 병합 패치 접근 방식과 유사한 개체 병합을 지원합니다. 둘의 차이점은 포드 사양의 컨테이너 배열을 포함하여 배열 교체만 지원한다는 점입니다. 이는 JSON 병합 패치를 사용할 때 컨테이너의 속성이 변경되는 경우 모든 컨테이너에 대한 완전한 사양을 제공해야 함을 의미합니다. 따라서 이 접근 방식은 BOM의 배열에서 요소를 제거하는 데 유용합니다. 명령줄에서 다음을 사용하여 JSON 병합 패치를 선택할 수 있습니다. kubectl patch --type=merge. Kubernetes API로 작업할 때 요청 메소드를 사용해야 합니다. PATCH 및 설치 content-type в application/merge-patch+json.

JSON 패치 접근 방식은 리소스의 부분 사양을 제공하는 대신 리소스에 적용하려는 변경 사항을 배열로 제공하는 방식을 사용합니다. 여기서 배열의 각 요소는 리소스에 적용된 변경 사항에 대한 설명을 나타냅니다. 이 접근 방식은 변경 사항을 표현하는 더 유연하고 강력한 방법이지만, 부분 리소스 사양을 보내는 대신 Kubernetes가 아닌 별도의 형식으로 변경 사항을 나열하는 비용이 듭니다. 안에 kubectl 다음을 사용하여 JSON 패치를 선택할 수 있습니다. kubectl patch --type=json. Kubernetes API를 사용할 때 이 접근 방식은 요청 메서드를 사용하여 작동합니다. PATCH 및 설치 content-type в application/json-patch+json.

자신감이 필요합니다 - 교체를 사용하세요

어떤 경우에는 리소스를 읽는 시간과 업데이트되는 시간 사이에 리소스가 변경되지 않았는지 확인해야 합니다. 즉, 모든 변경 사항이 적용되는지 확인해야 합니다. 원자. 이 경우 리소스를 업데이트하려면 다음을 사용해야 합니다. replace. 예를 들어 여러 소스에 의해 업데이트되는 카운터가 있는 ConfigMap이 있는 경우 두 소스가 동시에 카운터를 업데이트하여 업데이트가 손실되지 않도록 해야 합니다. 시연하려면 접근 방식을 사용하여 일련의 이벤트를 상상해 보세요. patch:

• A와 B는 API에서 리소스의 현재 상태를 가져옵니다.
• 각각은 카운터를 XNUMX씩 증가시키고 "업데이트자" 메모에 각각 "A" 또는 "B"를 추가하여 사양을 로컬로 업데이트합니다.
• 그리고 리소스를 조금 더 빠르게 업데이트합니다.
• B는 리소스를 업데이트합니다.

결과적으로 업데이트 A가 손실됩니다. 마지막 작업 patch 이기면 카운터는 XNUMX가 아닌 XNUMX씩 증가하고 "updated-by" 메모의 값은 "B"로 끝나며 "A"를 포함하지 않습니다. 위의 내용을 접근 방식을 사용하여 업데이트가 완료될 때 발생하는 상황과 비교해 보겠습니다. replace:

• A와 B는 API에서 리소스의 현재 상태를 가져옵니다.
• 각각은 카운터를 XNUMX씩 증가시키고 "업데이트자" 메모에 각각 "A" 또는 "B"를 추가하여 사양을 로컬로 업데이트합니다.
• 그리고 리소스를 조금 더 빠르게 업데이트합니다.
• B는 리소스 업데이트를 시도하지만 리소스 버전이 사양에 포함되어 있기 때문에 API에서 업데이트를 거부합니다. replace 리소스 버전이 A의 교체 작업에 의해 증가되었기 때문에 Kubernetes에 있는 리소스의 현재 버전과 일치하지 않습니다.

위의 경우 B는 리소스를 다시 가져와서 새 상태로 변경하고 다시 시도해야 합니다. replace. 이렇게 하면 카운터가 XNUMX만큼 증가하고 "업데이트 기준" 메모 끝에 "AB"가 포함됩니다.

위의 예는 실행할 때 replace 전체 리소스가 완전히 대체됩니다. 사용되는 사양 replace, 부분적이거나 부분적으로 이루어져서는 안 됩니다. apply, 그러나 추가를 포함하여 완료되었습니다. resourceVersion 사양 메타데이터에 추가됩니다. 활성화하지 않은 경우 resourceVersion 제공한 버전이 최신 버전이 아니면 교체가 거부됩니다. 따라서 가장 좋은 사용 방법은 replace – 리소스를 읽고 업데이트하고 즉시 교체하십시오. 사용 kubectl, 다음과 같이 보일 수 있습니다.

$ kubectl get deployment my-deployment -o json 
    | jq '.spec.template.spec.containers[0].env[1].value = "new value"' 
    | kubectl replace -f -

순차적으로 실행되는 다음 두 명령이 성공적으로 실행된다는 점은 주목할 가치가 있습니다. deployment.yaml 속성을 포함하지 않습니다 .metadata.resourceVersion

$ kubectl create -f deployment.yaml
$ kubectl replace -f deployment.yaml

이는 위에서 말한 내용과 모순되는 것처럼 보입니다. "첨가 resourceVersion 사양 메타데이터에 포함됩니다."라고 말하는 것이 잘못된 것인가요? 아니요, 그렇지 않습니다. kubectl 귀하가 지정하지 않은 알림 resourceVersion, 리소스에서 읽어서 지정한 사양에 추가한 다음 실행합니다. replace. 원자성에 의존하면 잠재적으로 위험할 수 있으므로 마법은 전적으로 측면에서 작동합니다. kubectl, API와 함께 작동하는 클라이언트 라이브러리를 사용할 때 이에 의존해서는 안 됩니다. 이 경우 현재 리소스 사양을 읽고 업데이트한 다음 실행해야 합니다. PUT 요구.

패치를 할 수는 없습니다. 교체 작업을 수행합니다.

때로는 API에서 처리할 수 없는 일부 변경 작업을 수행해야 하는 경우도 있습니다. 이러한 경우 리소스를 삭제하고 다시 생성하여 리소스를 강제로 교체할 수 있습니다. 이는 다음을 사용하여 수행됩니다. kubectl replace --force. 명령을 실행하면 리소스가 즉시 제거된 다음 제공된 사양에서 다시 생성됩니다. API에는 "강제 교체" 핸들러가 없으며 API를 통해 이를 수행하려면 두 가지 작업을 수행해야 합니다. 먼저 리소스를 설정하여 삭제해야 합니다. gracePeriodSeconds 영(0)으로 propagationPolicy "백그라운드"에서 원하는 사양으로 이 리소스를 다시 생성합니다.

경고: 이 접근 방식은 잠재적으로 위험하며 정의되지 않은 상태로 이어질 수 있습니다.

서버 측에서 적용

위에서 언급했듯이 Kubernetes 개발자는 로직을 구현하기 위해 노력하고 있습니다. apply 으로 kubectl Kubernetes API에서. 논리 apply Kubernetes 1.18에서 다음을 통해 사용 가능 kubectl apply --server-side 또는 API를 통해 메소드를 사용하여 PATCH с content-type application/apply-patch+YAML.

참고: JSON도 유효한 YAML이므로 다음과 같은 경우에도 사양을 JSON으로 보낼 수 있습니다. content-type 의지 application/apply-patch+yaml.

그 논리 외에 kubectl API를 통해 모든 사람이 사용할 수 있게 되었으며, apply 서버 측에서는 사양의 필드를 담당하는 사람을 추적하여 충돌 없는 편집을 위한 안전한 다중 액세스를 허용합니다. 즉, 만약 apply 서버 측에서는 더 널리 보급될 것이며 kubectl, Pulumi 또는 Terraform, GitOps와 같은 다양한 클라이언트에 대한 범용 보안 리소스 관리 인터페이스는 물론 클라이언트 라이브러리를 사용하는 자체 작성 스크립트도 나타날 것입니다.

결과

클러스터의 리소스를 업데이트하는 다양한 방법에 대한 간략한 개요가 도움이 되었기를 바랍니다. 단순히 적용과 교체가 아니라 적용, 편집, 패치 또는 교체를 사용하여 리소스를 업데이트할 수 있다는 점을 알아두면 좋습니다. 결국 원칙적으로 각 접근 방식에는 고유한 적용 영역이 있습니다. Atomic 변경의 경우 교체가 바람직하고, 그렇지 않은 경우 적용을 통해 전략적 병합 패치를 사용해야 합니다. 최소한 "kubernetes 적용 대 교체"를 검색할 때 Google이나 StackOerflow를 신뢰할 수 없다는 점을 이해해 주시기 바랍니다. 적어도 이 기사가 현재 답변을 대체할 때까지는 말이죠.

출처 : habr.com