Kubernetes를 사용할 때 흔히 저지르는 10가지 실수

메모. 번역: 이 글의 저자는 체코의 소규모 회사인 파이프테일(pipetail)의 엔지니어입니다. 그들은 Kubernetes 클러스터 운영과 관련된 [때때로 진부하지만 여전히] 매우 시급한 문제와 오해의 멋진 목록을 정리했습니다.

지난 수년간 Kubernetes를 사용하면서 우리는 수많은 클러스터(GCP, AWS 및 Azure에서 관리형 및 비관리형 모두)를 사용해 왔습니다. 시간이 지남에 따라 우리는 일부 실수가 지속적으로 반복된다는 것을 알아차리기 시작했습니다. 그러나 여기에는 부끄러운 것이 없습니다. 대부분의 작업은 우리가 직접 수행했습니다!

이 기사에는 가장 일반적인 오류가 포함되어 있으며 이를 수정하는 방법도 언급되어 있습니다.

1. 리소스: 요청 및 제한

이 항목은 확실히 가장 주목을 받고 목록에서 XNUMX위를 차지할 가치가 있습니다.

일반적으로 CPU 요청 전혀 지정되지 않았거나 값이 매우 낮음 (각 노드에 가능한 한 많은 포드를 배치하기 위해) 따라서 노드가 과부하됩니다. 로드가 높은 시간에는 노드의 처리 능력이 완전히 활용되고 특정 워크로드는 노드에서 "요청한" 것만 수신합니다. CPU 조절. 이로 인해 애플리케이션 대기 시간, 시간 초과 및 기타 불쾌한 결과가 증가합니다. (이에 대한 자세한 내용은 최근 다른 번역에서 읽어보세요: “Kubernetes의 CPU 제한 및 공격적인 조절" - 약. 번역)

최고의 노력 (극도로 아니 권장):

resources: {}

매우 낮은 CPU 요청(매우 아니 권장):

   resources:
      Requests:
        cpu: "1m"

반면에 CPU 제한이 있으면 노드 프로세서가 완전히 로드되지 않은 경우에도 포드에서 클록 주기를 비합리적으로 건너뛸 수 있습니다. 다시 말하지만 이로 인해 지연이 증가할 수 있습니다. 매개변수를 둘러싼 논란은 계속된다 CPU CFS 할당량 설정된 제한에 따라 Linux 커널 및 CPU 조절, CFS 할당량 비활성화... 아쉽게도 CPU 제한은 해결할 수 있는 것보다 더 많은 문제를 일으킬 수 있습니다. 이에 대한 자세한 내용은 아래 링크에서 확인하실 수 있습니다.

과도한 선택 (오버 커밋) 메모리 문제는 더 큰 문제로 이어질 수 있습니다. CPU 한도에 도달하면 클록 주기를 건너뛰게 되고, 메모리 한도에 도달하면 포드가 종료됩니다. 관찰한 적이 있나요? OOM킬? 예, 그것이 바로 우리가 말하는 것입니다.

이런 일이 발생할 가능성을 최소화하고 싶습니까? 메모리를 과도하게 할당하지 말고 메모리 요청을 한도로 설정하여(아래 예와 같이) 보장된 QoS(서비스 품질)를 사용하세요. 이에 대해 자세히 알아보세요. 헤닝 제이콥스 프레젠테이션 (Zalando의 수석 엔지니어)

버스트 가능 (OOMkill이 발생할 확률이 높아짐):

   resources:
      requests:
        memory: "128Mi"
        cpu: "500m"
      limits:
        memory: "256Mi"
        cpu: 2

보장:

   resources:
      requests:
        memory: "128Mi"
        cpu: 2
      limits:
        memory: "128Mi"
        cpu: 2

리소스를 설정할 때 잠재적으로 도움이 되는 것은 무엇입니까?

과 메트릭 서버 Pod(및 그 안에 있는 컨테이너)별 현재 CPU 리소스 소비 및 메모리 사용량을 확인할 수 있습니다. 아마도 이미 사용하고 있을 가능성이 높습니다. 다음 명령을 실행하면 됩니다.

kubectl top pods
kubectl top pods --containers
kubectl top nodes

그러나 현재 사용량만 표시됩니다. 이를 통해 크기 순서에 대한 대략적인 아이디어를 얻을 수 있지만 궁극적으로는 다음이 필요합니다. 시간 경과에 따른 측정항목 변경 내역 (예: "최고 CPU 로드는 얼마였나요?", "어제 아침 로드는 얼마였나요?" 등과 같은 질문에 답하기 위해) 이를 위해 다음을 사용할 수 있습니다. 프로 메테우스, 데이터 도그 및 기타 도구. 단순히 메트릭 서버에서 메트릭을 가져와 저장하면 사용자는 이를 쿼리하고 그에 따라 플롯할 수 있습니다.

VerticalPodAutoscaler 그것은 수 있습니다 자동화하다 이 과정. CPU 및 메모리 사용 내역을 추적하고 이 정보를 기반으로 새로운 요청 및 제한을 설정합니다.

컴퓨팅 성능을 효율적으로 사용하는 것은 쉬운 일이 아닙니다. 항상 테트리스 게임을 하는 것과 같습니다. 낮은 평균 소비(예: 10%)로 컴퓨팅 성능에 너무 많은 비용을 지불하고 있다면 AWS Fargate 또는 Virtual Kubelet 기반 제품을 살펴보는 것이 좋습니다. 이는 서버리스/종량제 결제 모델을 기반으로 구축되었으며, 이러한 조건에서는 더 저렴할 수 있습니다.

2. 활동성 및 준비 상태 프로브

기본적으로 Kubernetes에서는 활성 상태 및 준비 상태 확인이 활성화되어 있지 않습니다. 그리고 때로는 전원을 켜는 것을 잊어버릴 때도 있습니다...

하지만 치명적인 오류가 발생한 경우 서비스를 다시 시작하려면 어떻게 해야 할까요? 그리고 로드 밸런서는 포드가 트래픽을 수용할 준비가 되었는지 어떻게 알 수 있나요? 아니면 더 많은 트래픽을 처리할 수 있습니까?

이러한 테스트는 종종 서로 혼동됩니다.

• 생동감 — "생존 가능성" 검사 - 실패할 경우 포드를 다시 시작합니다.
• 준비 — 준비 확인, 실패하면 Kubernetes 서비스에서 포드 연결을 끊습니다(이는 다음을 사용하여 확인할 수 있습니다). kubectl get endpoints) 다음 확인이 성공적으로 완료될 때까지 트래픽이 도착하지 않습니다.

이 두 가지 검사 모두 포드의 전체 수명 주기 동안 수행됩니다.. 그것은 매우 중요합니다.

일반적인 오해는 준비 상태 프로브가 시작 시에만 실행되어 밸런서가 포드가 준비되었음을 알 수 있다는 것입니다(Ready) 트래픽 처리를 시작할 수 있습니다. 그러나 이는 사용 옵션 중 하나일 뿐입니다.

또 다른 하나는 Pod의 트래픽이 과도하다는 것을 알아낼 가능성이며, 과부하가 걸리다 (또는 포드가 리소스 집약적인 계산을 수행함) 이 경우 준비 상태 확인이 도움이 됩니다. 포드의 부하를 줄이고 포드를 "냉각"시킵니다.. 향후 준비 상태 확인을 성공적으로 완료하면 포드의 부하를 다시 늘립니다.. 이 경우(준비 테스트가 실패하면) 활성 테스트 실패는 매우 비생산적입니다. 건강하고 열심히 일하는 포드를 다시 시작하는 이유는 무엇입니까?

따라서 어떤 경우에는 잘못 구성된 매개변수를 사용하여 활성화하는 것보다 전혀 확인하지 않는 것이 더 좋습니다. 위에서 말한 대로라면, 활성 확인 복사본 준비 확인, 그렇다면 당신은 큰 어려움에 처해 있습니다. 가능한 옵션은 구성하는 것입니다 준비 테스트만과 위험한 생명력 따로 남겨두세요.

공통 종속성이 실패할 때 두 가지 유형의 검사 모두 실패해서는 안 됩니다. 그렇지 않으면 모든 Pod에 계단식(눈사태와 같은) 오류가 발생하게 됩니다. 다시 말해서, 자신에게 해를 끼치 지 마십시오.

3. 각 HTTP 서비스에 대한 LoadBalancer

아마도 클러스터에는 외부로 전달하려는 HTTP 서비스가 있을 것입니다.

다음과 같이 서비스를 열면 type: LoadBalancer, 해당 컨트롤러(서비스 제공업체에 따라 다름)는 외부 LoadBalancer(반드시 L7에서 실행될 필요는 없지만 L4에서도 실행됨)를 제공하고 협상하며 이는 비용(외부 정적 IPv4 주소, 컴퓨팅 성능, 초당 청구)에 영향을 미칠 수 있습니다. ) 그러한 리소스를 많이 생성해야 하기 때문입니다.

이 경우 하나의 외부 로드 밸런서를 사용하여 서비스를 다음과 같이 여는 것이 훨씬 더 논리적입니다. type: NodePort. 아니면 더 나은 방법은 다음과 같이 확장하는 것입니다. nginx-수신-컨트롤러 (또는 Traefik), 누가 유일한 사람이 될 것인가? 노드포트 외부 로드 밸런서와 연결된 엔드포인트이며 다음을 사용하여 클러스터의 트래픽을 라우팅합니다. 입구-쿠버네티스 리소스.

서로 상호 작용하는 다른 클러스터 내(마이크로) 서비스는 다음과 같은 서비스를 사용하여 "통신"할 수 있습니다. 클러스터IP DNS를 통한 내장형 서비스 검색 메커니즘. 공용 DNS/IP를 사용하지 마십시오. 지연 시간에 영향을 미치고 클라우드 서비스 비용이 증가할 수 있습니다.

4. 클러스터 기능을 고려하지 않고 클러스터 자동 확장

클러스터에 노드를 추가하고 제거할 때 해당 노드의 CPU 사용량과 같은 일부 기본 측정항목에 의존해서는 안 됩니다. 포드 계획에는 많은 사항을 고려해야 합니다. 제한, 포드/노드 선호도, 오염 및 허용, 리소스 요청, QoS 등과 같은 이러한 미묘한 차이를 고려하지 않은 외부 자동 크기 조정기를 사용하면 문제가 발생할 수 있습니다.

특정 포드를 예약해야 하지만 사용 가능한 모든 CPU 성능이 요청/분해되고 포드가 예약된다고 상상해 보세요. 상태에 걸리다 Pending. 외부 자동 확장 처리는 평균 현재 CPU 로드(요청된 로드가 아님)를 확인하고 확장을 시작하지 않습니다. (스케일 아웃) - 다른 노드를 추가하지 않습니다. 따라서 이 포드는 예약되지 않습니다.

이 경우 역스케일링 (스케일인) — 클러스터에서 노드를 제거하는 것은 항상 구현하기가 더 어렵습니다. 상태 저장 포드(영구 스토리지가 연결되어 있음)가 있다고 상상해 보세요. 영구 볼륨 보통 속해있다 특정 가용성 영역 해당 지역에서는 복제되지 않습니다. 따라서 외부 자동 크기 조정기가 이 Pod가 있는 노드를 삭제하는 경우 스케줄러는 이 Pod를 다른 노드에서 예약할 수 없습니다. 이는 영구 저장소가 있는 가용성 영역에서만 수행할 수 있기 때문입니다. 포드가 해당 상태에서 멈춥니다. Pending.

Kubernetes 커뮤니티에서 매우 인기 있음 클러스터 자동 크기 조정기. 클러스터에서 실행되고, 주요 클라우드 제공업체의 API를 지원하며, 모든 제한 사항을 고려하고 위의 경우에 확장할 수 있습니다. 또한 설정된 모든 제한을 유지하면서 규모를 축소할 수 있으므로 비용을 절약할 수 있습니다(그렇지 않으면 사용하지 않는 용량에 소비하게 됨).

5. IAM/RBAC 기능 무시

영구 보안 비밀을 가진 IAM 사용자를 사용하는 것에 주의하세요. 기계 및 응용 프로그램. 역할 및 서비스 계정을 사용하여 임시 액세스 구성 (서비스 계정).

우리는 액세스 키(및 보안 비밀)가 애플리케이션 구성에 하드코딩되어 있고 Cloud IAM에 액세스할 수 있음에도 불구하고 보안 비밀 순환을 무시한다는 사실을 자주 접합니다. 적절한 경우 사용자 대신 IAM 역할 및 서비스 계정을 사용합니다.

kube2iam은 잊어버리고 서비스 계정에 대한 IAM 역할로 바로 이동하세요(에 설명된 대로). 같은 이름의 메모 슈테판 브라니(Štěpán Vraný):

apiVersion: v1
kind: ServiceAccount
metadata:
  annotations:
    eks.amazonaws.com/role-arn: arn:aws:iam::123456789012:role/my-app-role
  name: my-serviceaccount
  namespace: default

주석 하나. 그렇게 어렵지는 않죠?

또한 서비스 계정 및 인스턴스 프로필 권한을 부여하지 마세요. admin и cluster-admin필요하지 않다면. 이는 특히 RBAC K8에서 구현하기가 조금 더 어렵지만 확실히 노력할만한 가치가 있습니다.

6. Pod에 대한 자동 반친화성에 의존하지 마세요.

노드에 일부 배포의 복제본이 XNUMX개 있다고 가정해 보겠습니다. 노드가 떨어지고 모든 복제본도 함께 떨어집니다. 불쾌한 상황이죠? 그런데 왜 모든 복제본이 동일한 노드에 있었습니까? Kubernetes는 고가용성(HA)을 제공해야 하지 않나요?!

불행하게도 Kubernetes 스케줄러는 자체적으로 별도의 존재 규칙을 준수하지 않습니다. (반친화성) 포드용. 명시적으로 명시해야 합니다.

// опущено для краткости
      labels:
        app: zk
// опущено для краткости
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: "app"
                    operator: In
                    values:
                    - zk
              topologyKey: "kubernetes.io/hostname"

그게 다야. 이제 포드는 다른 노드에 예약됩니다(이 조건은 예약 중에만 확인되고 작업 중에는 확인되지 않습니다. requiredDuringSchedulingIgnoredDuringExecution).

여기서 우리는 podAntiAffinity 다른 노드에서: topologyKey: "kubernetes.io/hostname", - 다른 가용성 영역에 관한 것이 아닙니다. 완전한 HA를 구현하려면 이 주제를 더 자세히 살펴봐야 합니다.

7. PodDisruptionBudget 무시

Kubernetes 클러스터에 프로덕션 로드가 있다고 가정해 보세요. 주기적으로 노드와 클러스터 자체를 업데이트(또는 서비스 해제)해야 합니다. PodDisruptionBudget(PDB)은 클러스터 관리자와 사용자 간의 서비스 보증 계약과 비슷합니다.

PDB를 사용하면 노드 부족으로 인한 서비스 중단을 방지할 수 있습니다.

apiVersion: policy/v1beta1
kind: PodDisruptionBudget
metadata:
  name: zk-pdb
spec:
  minAvailable: 2
  selector:
    matchLabels:
      app: zookeeper

이 예에서는 클러스터 사용자로서 관리자에게 다음과 같이 말합니다. "저에게는 사육사 서비스가 있습니다. 무엇을 하든 이 서비스의 복제본을 항상 2개 이상 사용할 수 있도록 하고 싶습니다."

이에 대해 더 자세히 읽을 수 있습니다. 여기에.

8. 공통 클러스터의 여러 사용자 또는 환경

Kubernetes 네임스페이스 (네임스페이스) 강한 절연을 제공하지 마십시오.

일반적인 오해는 비프로덕션 로드를 한 네임스페이스에 배포하고 프로덕션 로드를 다른 네임스페이스에 배포하면 어떤 식으로든 서로 영향을 미치지 않을 것입니다... 그러나 리소스 요청/제한, 할당량 설정 및 PriorityClasses 설정을 사용하여 특정 수준의 격리를 달성할 수 있습니다. 데이터 플레인의 일부 "물리적" 격리는 유사성, 허용성, 오염(또는 노드 선택기)에 의해 제공되지만 이러한 분리는 상당히 어려운 구현하다.

동일한 클러스터에서 두 가지 유형의 워크로드를 결합해야 하는 경우 복잡성을 처리해야 합니다. 그러한 필요성이 없고 하나를 가질 여유가 있는 경우 클러스터 하나 더 (예를 들어 퍼블릭 클라우드에서) 그렇게 하는 것이 더 좋습니다. 이렇게 하면 훨씬 더 높은 수준의 단열 효과를 얻을 수 있습니다.

9. 외부 트래픽 정책: 클러스터

클러스터 내부의 모든 트래픽이 기본 정책이 설정된 NodePort와 같은 서비스를 통해 들어오는 것을 매우 자주 볼 수 있습니다. externalTrafficPolicy: Cluster. 즉, 노드포트 클러스터의 모든 노드에 열려 있으며, 이를 사용하여 원하는 서비스(포드 세트)와 상호 작용할 수 있습니다.

동시에 위에서 언급한 NodePort 서비스와 관련된 실제 포드는 일반적으로 특정 네트워크에서만 사용할 수 있습니다. 이 노드의 하위 집합. 즉, 필요한 포드가 없는 노드에 연결하면 다른 노드로 트래픽을 전달하고, 홉 추가 대기 시간 증가(노드가 서로 다른 가용성 영역/데이터 센터에 위치한 경우 대기 시간이 상당히 길어질 수 있으며, 또한 송신 트래픽 비용도 증가합니다).

반면 특정 Kubernetes 서비스에 정책 세트가 있는 경우 externalTrafficPolicy: Local, 그러면 NodePort는 필요한 Pod가 실제로 실행 중인 노드에서만 열립니다. 상태를 확인하는 외부 로드밸런서를 사용하는 경우 (건강검진) 엔드포인트(어떻게 작동합니까? AWS ELB), 그 필요한 노드에만 트래픽을 보냅니다., 이는 지연, 컴퓨팅 요구 사항, 송신 청구서에 유익한 영향을 미칠 것입니다(상식적으로도 동일함).

이미 다음과 같은 것을 사용하고 있을 가능성이 높습니다. Traefik 또는 nginx-수신-컨트롤러 NodePort 엔드포인트(또는 NodePort를 사용하는 LoadBalancer)로 HTTP 수신 트래픽을 라우팅하고 이 옵션을 설정하면 해당 요청에 대한 대기 시간을 크게 줄일 수 있습니다.

В 이 간행물 externalTrafficPolicy의 장점과 단점에 대해 자세히 알아볼 수 있습니다.

10. 클러스터에 얽매이지 말고 컨트롤 플레인을 남용하지 마세요.

이전에는 고유한 이름으로 서버를 호출하는 것이 관례였습니다. 안톤, HAL9000 및 Colossus... 현재는 무작위로 생성된 식별자로 대체되었습니다. 그러나 그 습관은 그대로 남아 이제는 고유명사가 클러스터로 이동합니다.

전형적인 이야기(실제 사건을 기반으로 함): 모든 것이 개념 증명으로 시작되었으므로 클러스터는 자랑스러운 이름을 갖게 되었습니다. 테스트… 몇 년이 지났지만 여전히 생산에 사용되며 모두가 만지기를 두려워합니다.

클러스터가 펫으로 변하는 것은 재미가 없으므로 연습하면서 주기적으로 제거하는 것이 좋습니다. 재해 복구 (이것이 도움이 될 것입니다 카오스 엔지니어링 - 대략. 번역). 또한 컨트롤 레이어에서 작업해도 문제가 되지 않습니다. (제어 평면). 그를 만지기를 두려워하는 것은 좋은 징조가 아닙니다. 기타 죽은? 여러분, 정말 고생하셨습니다!

반면에 그것을 조작하는 데 푹 빠져서는 안됩니다. 시간이 지나면 컨트롤 레이어가 느려질 수 있습니다. 아마도 이는 회전 없이 생성된 많은 수의 객체 때문일 것입니다(기본 설정으로 Helm을 사용할 때 일반적인 상황이므로 configmaps/secrets의 상태가 업데이트되지 않습니다. 결과적으로 수천 개의 객체가 제어 계층) 또는 kube-api 객체의 지속적인 편집(자동 확장, CI/CD, 모니터링, 이벤트 로그, 컨트롤러 등)을 통해 가능합니다.

또한 관리형 Kubernetes 공급자와의 SLA/SLO 계약을 확인하고 보증에 주의하는 것이 좋습니다. 판매자는 보증할 수 있습니다. 제어 계층 가용성 (또는 그 하위 구성 요소)이지만 보내는 요청의 p99 지연은 아닙니다. 즉, 다음과 같이 입력할 수 있습니다. kubectl get nodes, 그리고 10분 후에야 답변을 받을 수 있으며 이는 서비스 계약 조건을 위반하지 않습니다.

11. 보너스: 최신 태그 사용

그러나 이것은 이미 고전입니다. 최근에 우리는 쓰라린 경험을 통해 배운 많은 사람들이 태그 사용을 중단했기 때문에 이 기술을 덜 자주 접했습니다. :latest 버전 고정을 시작했습니다. 만세!

ECR 이미지 태그의 불변성을 유지합니다.; 이 놀라운 기능에 익숙해지는 것이 좋습니다.

개요

모든 것이 하룻밤 사이에 작동할 것이라고 기대하지 마십시오. Kubernetes는 만병통치약이 아닙니다. 나쁜 앱 Kubernetes에서도 이런 식으로 유지됩니다 (아마도 상황은 더욱 악화될 것입니다). 부주의는 제어 계층의 과도한 복잡성, 느리고 스트레스가 많은 작업으로 이어질 것입니다. 또한 재해 복구 전략이 없이 방치될 위험이 있습니다. Kubernetes가 기본적으로 격리 및 고가용성을 제공할 것이라고 기대하지 마십시오. 애플리케이션을 진정한 클라우드 네이티브로 만드는 데 시간을 투자하세요.

다양한 팀의 실패한 경험에 대해 알 수 있습니다. 이 이야기 모음 헤닝 제이콥스.

이 기사에 제공된 오류 목록에 추가하려는 경우 Twitter(@MarekBartik, @MstrsObserver).

번역가의 추신

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

• «Kubernetes 클러스터 설계: 몇 개가 있어야 합니까?";
• «Kubernetes 보안의 ABC: 인증, 권한 부여, 감사";
• «Kubernetes의 자동 크기 조정 및 리소스 관리"(리뷰 및 영상보고);
• «Kubernetes의 ConfigMap: 알아야 할 미묘한 차이".

출처 : habr.com