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

메모. 번역: 이 기사의 저자는 pipetail이라는 체코의 소규모 회사의 엔지니어입니다. 그들은 Kubernetes 클러스터 운영과 관련된 [때로는 사소하지만 여전히] 매우 관련성 있는 문제와 오해에 대한 훌륭한 목록을 작성했습니다.

수년간 Kubernetes를 사용하면서 우리는 많은 수의 클러스터(GCP, AWS, Azure에서 관리형 및 비관리형 모두)를 다루었습니다. 시간이 지나면서 우리는 일부 실수가 끊임없이 반복된다는 것을 알아차리기 시작했습니다. 하지만 이는 부끄러운 일이 아닙니다. 우리 스스로가 대부분의 죄를 지었기 때문입니다!

이 기사에서는 가장 흔한 오류에 대해 설명하고 이를 수정하는 방법도 설명합니다.

1. 리소스: 요청 및 제한

이 지점은 확실히 가장 많은 주목을 받고 목록의 첫 번째 자리를 차지할 만합니다.

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

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

resources: {}

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

   resources:
      Requests:
        cpu: "1m"

반면, CPU 제한이 있으면 노드의 CPU가 완전히 로드되지 않았더라도 포드가 불필요하게 사이클을 건너뛸 수 있습니다. 이로 인해 지연 시간이 늘어날 수 있습니다. 매개변수를 둘러싼 논란은 계속되고 있다 CPU CFS 할당량 핵심에 Linux 설정된 제한에 따라 CPU 사용량이 제한되거나 CFS 할당량이 비활성화될 수 있지만, 안타깝게도 CPU 제한은 문제를 해결하기보다는 더 많은 문제를 야기할 수 있습니다. 자세한 내용은 아래 링크에서 확인하세요.

과도한 분비 (과도한 약속) 기억은 더 광범위한 문제로 이어질 수 있습니다. CPU 한계에 도달하면 사이클이 건너뛰어지고, 메모리 한계에 도달하면 포드가 종료됩니다. 당신은 그것을 관찰한 적이 있나요? 움킬? 네, 바로 그거에 대해 이야기하고 있어요.

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

버스트 가능 (OOMkilled를 받을 확률이 더 높음):

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

보장:

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

리소스를 설정할 때 무엇이 ​​도움이 될 수 있나요?

과 메트릭 서버 포드(및 포드 내 컨테이너)의 현재 CPU 소비량과 메모리 사용량을 볼 수 있습니다. 아마도 여러분은 이미 그것을 사용하고 있을 겁니다. 다음 명령을 실행하세요.

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

하지만 현재 사용량만 보여줍니다. 그것은 당신에게 대략적인 규모에 대한 아이디어를 줄 수 있지만 궁극적으로 당신에게 필요할 것입니다 시간 경과에 따른 메트릭 변경 내역 ("최대 CPU 부하가 얼마였나요?", "어제 아침 부하가 얼마였나요?" 등과 같은 질문에 답하기 위해) 이를 위해 다음을 사용할 수 있습니다. 프로 메테우스, 데이터 도그 및 기타 도구. 그들은 단순히 metrics-server에서 지표를 가져와 저장하고, 사용자는 이를 쿼리하여 해당 그래프를 작성할 수 있습니다.

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

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

2. 활성도 및 준비도 프로브

기본적으로 Kubernetes에서는 활성 상태 및 준비 상태 검사가 활성화되어 있지 않습니다. 그리고 가끔은 켜는 것을 잊어버리기도 합니다...

하지만 복구할 수 없는 오류가 발생한 경우 서비스를 다시 시작할 수 있는 다른 방법은 무엇일까요? 그러면 로드 밸런서는 특정 포드가 트래픽을 수신할 준비가 되었는지 어떻게 알 수 있을까요? 아니면 더 많은 교통량을 처리할 수 있을까?

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

• 생동감 - 실패할 경우 포드를 다시 시작하는 "활성" 검사
• 준비 — 준비 확인이 실패하면 Kubernetes 서비스에서 Pod 연결이 끊어집니다(다음을 사용하여 확인할 수 있음). kubectl get endpoints) 그리고 다음 점검이 성공적으로 완료될 때까지 교통량이 도착하지 않습니다.

두 테스트 모두 POD의 전체 수명 주기 동안 수행됩니다.. 이건 매우 중요해요.

준비 프로브는 로드 밸런서에 포드가 준비되었음을 알리기 위해 시작 시에만 실행된다는 것은 일반적인 오해입니다.Ready) 트래픽 처리를 시작할 수 있습니다. 하지만 이것은 그 사용 방법 중 하나일 뿐입니다.

또 다른 하나는 포드의 트래픽이 지나치게 높을 때를 알 수 있는 기능입니다. 그것을 과부하시킨다 (또는 포드가 리소스를 많이 사용하는 계산을 수행하고 있는 경우). 이 경우 준비성 확인이 도움이 됩니다. 포드의 부하를 줄이고 "냉각"하세요. 향후 준비성 점검을 성공적으로 완료하면 포드에 다시 부하를 증가시키다. 이 경우(준비 테스트가 실패하면) 활성 테스트에 실패하는 것은 매우 역효과가 있을 것입니다. 건강하고 열심히 작동하는 포드를 왜 다시 시작해야 합니까?

따라서 어떤 경우에는 잘못 구성된 매개변수로 검사를 활성화하는 것보다 검사를 전혀 하지 않는 것이 더 나을 수 있습니다. 위에서 언급했듯이, 활성 여부 확인 사본 준비 상태 확인, 그러면 당신은 큰 곤경에 처하게 될 것입니다. 가능한 옵션은 구성하는 것입니다 준비 테스트만과 위험한 활력 따로 두세요.

공통 종속성이 실패할 경우 두 가지 유형의 검사가 모두 실패해서는 안 됩니다. 그렇지 않으면 모든 포드가 연쇄적으로 실패하게 됩니다. 다시 말해서, 자신을 해치지 마세요.

3. 각 HTTP 서비스에 대한 LoadBalancer

클러스터에 외부 세계에 공개하고 싶은 HTTP 서비스가 있을 가능성이 큽니다.

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

이 경우 하나의 외부 로드 밸런서를 사용하여 서비스를 여는 것이 훨씬 더 합리적입니다. type: NodePort. 또는 더 나은 방법으로 다음과 같은 것을 배포합니다. nginx-ingress-controller (또는 Traefik), 유일하게 공연할 사람이 될 사람 노드포트 외부 로드 밸런서와 연결된 엔드포인트이며 클러스터 내에서 트래픽을 라우팅합니다. 입구-쿠버네티스 리소스.

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

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

클러스터에 노드를 추가하거나 제거할 때 해당 노드의 CPU 사용량과 같은 일부 기본 지표에 의존해서는 안 됩니다. Pod 스케줄링은 다음 사항을 고려하여 수행되어야 합니다. 제한예를 들어, 포드/노드 친화성, 오염 및 허용, 리소스 요청, QoS 등이 있습니다. 이러한 미묘한 차이를 고려하지 않는 외부 자동 확장기를 사용하면 문제가 발생할 수 있습니다.

포드를 예약해야 하지만 사용 가능한 CPU 용량이 모두 요청/점유되고 포드가 있다고 가정해 보겠습니다. 상태에 갇히다 Pending. 외부 자동 확장기는 평균 현재 CPU 부하(요청된 부하 아님)를 확인하고 확장을 시작하지 않습니다. (스케일 아웃) - 다른 노드를 추가하지 않습니다. 따라서 이 포드는 예약되지 않습니다.

이 경우 역방향 스케일링 (스케일 인) - 클러스터에서 노드를 제거하는 것은 항상 구현하기가 더 어렵습니다. 상태 저장형 포드(영구 저장소가 연결됨)가 있다고 상상해보세요. 영구 볼륨 보통 ~에 속한다 특정 가용성 영역 해당 지역에서는 복제되지 않습니다. 따라서 외부 자동 확장기가 이 Pod가 있는 노드를 제거하면 스케줄러는 이 Pod를 다른 노드에 스케줄링할 수 없습니다. 이는 영구 저장소가 있는 가용성 영역에서만 가능하기 때문입니다. 포드는 상태에 갇히게 됩니다 Pending.

쿠버네티스 커뮤니티에서 매우 인기가 있습니다 클러스터 자동 크기 조정기. 클러스터에서 실행되고, 주요 클라우드 서비스 공급업체의 API를 지원하며, 모든 제한 사항을 고려하고 위의 경우에 확장이 가능합니다. 또한 설정된 한도를 모두 유지하면서 확장이 가능하므로 비용을 절감할 수 있습니다(그렇지 않으면 사용되지 않는 용량에 비용이 지출될 것입니다).

5. IAM/RBAC 기능 무시

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

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

kube2iam을 잊고 서비스 계정에 대한 IAM 역할로 바로 이동하세요(다음에서 설명). 같은 이름의 메모 스테판 브라니):

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, 필요하지 않다면요. 특히 K8s RBAC에서는 이를 구현하기가 조금 더 어렵지만, 그만한 노력은 충분히 가치가 있습니다.

6. 포드에 대한 자동 안티 친화성에 의존하지 마십시오.

노드에 배포의 복제본이 3개 있다고 가정해 보겠습니다. 노드가 사라지고 모든 복제본도 사라집니다. 불쾌한 상황이죠? 하지만 왜 모든 복제본이 같은 노드에 있었을까요? 쿠버네티스는 고가용성(HA)을 제공해야 하는 게 아닌가요?!

안타깝게도 쿠버네티스 스케줄러는 그 자체로 별도로 존재하는 규칙을 따르지 않습니다. (반친화성) 포드용. 다음 사항을 명확하게 명시해야 합니다.

// опущено для краткости
      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

이 예에서 클러스터 사용자는 관리자에게 "저는 Zookeeper 서비스를 사용하고 있는데, 무엇을 하든 이 서비스의 복제본을 최소 2개 이상 항상 사용할 수 있도록 해주세요."라고 말합니다.

이에 대한 자세한 내용은 여기에서 읽을 수 있습니다. 여기에.

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

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

비프로덕션 로드를 한 네임스페이스에 배포하고 프로덕션 로드를 다른 네임스페이스에 배포하면 다음과 같은 오해가 흔히 있습니다. 어떤 식으로든 서로 영향을 미치지 않을 것입니다... 그러나 리소스 요청/제한을 사용하고, 할당량을 설정하고, 우선순위 클래스를 지정하면 일정 수준의 격리를 달성할 수 있습니다. 데이터 평면의 일부 "물리적" 격리는 친화성, 허용, 오염(또는 노드 선택기)에 의해 제공되지만 이러한 분리는 매우 어려운 구현하다.

동일한 클러스터에서 두 가지 유형의 워크로드를 혼합해야 하는 사람들은 복잡성을 감수해야 합니다. 그러한 필요가 없고 구매할 여유가 있다면 또 다른 클러스터 (예를 들어, 퍼블릭 클라우드에서) 그렇게 하는 것이 더 좋습니다. 이를 통해 훨씬 더 높은 수준의 단열이 가능해집니다.

9. externalTrafficPolicy: 클러스터

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

동시에, 위에 언급된 NodePort 서비스와 연관된 실제 포드는 일반적으로 일부에서만 사용 가능합니다. 이러한 노드의 하위 집합. 즉, 필요한 Pod가 없는 노드에 연결하면 트래픽이 다른 노드로 전달됩니다. 홉 추가 그리고 지연 시간이 증가합니다(노드가 서로 다른 가용성 영역/데이터 센터에 있는 경우 지연 시간이 매우 길어질 수 있습니다. 또한, 이탈 트래픽 비용도 증가합니다).

반면, 특정 Kubernetes 서비스에 대한 정책이 정의된 경우 externalTrafficPolicy: Local그러면 NodePort는 필요한 포드가 실제로 실행 중인 노드에서만 열립니다. 상태를 확인하는 외부 로드 밸런서를 사용하는 경우 (건강검진) 엔드포인트(어떻게 하나요? AWS ELB), 그 필요한 노드에만 트래픽을 보냅니다.이는 지연 시간, 컴퓨팅 요구 사항, 퇴장 비용에 긍정적인 영향을 미칩니다(상식적으로도 마찬가지입니다).

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

В 이 간행물 externalTrafficPolicy에 대해 자세히 알아보고, 장점과 단점을 알아보세요.

10. 클러스터에 집착하지 말고 제어 평면을 과도하게 사용하지 마십시오.

이전에는 서버를 적절한 이름으로 부르는 것이 일반적이었습니다. 안톤, HAL9000 및 Colossus… 오늘날에는 무작위로 생성된 식별자로 대체되었습니다. 그러나 그 관습은 여전히 ​​남아 있었고, 지금은 클러스터에 고유명사가 붙습니다.

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

클러스터가 애완동물로 변하는 것에는 재미있는 것이 없으므로 연습하는 동안 주기적으로 제거하는 것이 좋습니다. 재해 복구 (이것은 도움이 될 것입니다 카오스 엔지니어링 - 대략. 번역). 게다가, 제어 계층에서 작업하는 것도 나쁘지 않을 겁니다. (제어 평면). 만지는 것을 두려워하는 것은 그다지 좋은 징조가 아닙니다. 기타 죽은? 여러분, 정말 큰 문제에 빠졌어요!

반면에, 그것을 조작하는 데 너무 빠져서는 안 됩니다. 시간이 지남에 따라 제어 계층이 느려질 수 있습니다. 이는 객체를 회전시키지 않고 대량으로 생성했기 때문일 가능성이 가장 높습니다(기본 설정으로 Helm을 사용할 때 흔히 발생하는 상황으로, configmaps/secrets의 상태가 업데이트되지 않아 제어 계층에 수천 개의 객체가 누적됨) 또는 kube-api 객체를 지속적으로 편집했기 때문일 수 있습니다(자동 확장, CI/CD, 모니터링, 이벤트 로그, 컨트롤러 등을 위해).

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

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

이건 이미 고전이에요. 최근에는 이 기술을 자주 볼 수 없게 되었는데, 많은 사람들이 쓰라린 경험을 통해 이 태그를 사용하지 않게 되었기 때문입니다. :latest 그리고 버전을 고정하기 시작했습니다. 만세!

ECR 이미지 태그 불변성을 유지합니다.; 이 놀라운 기능에 대해 미리 알아보시기 바랍니다.

개요

하룻밤 사이에 모든 것이 잘 될 거라고 기대하지 마세요. 쿠버네티스는 만병통치약이 아닙니다. 나쁜 앱 Kubernetes에서도 동일하게 유지됩니다 (그리고 상황이 더 나빠질 수도 있습니다). 부주의로 인해 제어 계층의 작업이 지나치게 복잡해지고, 느리고 스트레스가 많아집니다. 게다가 재해 복구 전략이 부재하게 될 위험도 있습니다. Kubernetes가 바로 격리와 고가용성을 처리할 수 있을 것이라고 기대하지 마세요. 시간을 내어 앱을 진정한 클라우드 네이티브로 만들어보세요.

다양한 팀의 실패 경험에 대해 읽어보세요. 이 이야기 모음 저자: 헤닝 제이콥스

이 기사에 나열된 오류 목록에 추가하고 싶은 사람은 Twitter에서 저희에게 연락할 수 있습니다.@마렉바틱, @MstrsObserver).

번역가의 추신

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

• «Kubernetes 클러스터 설계: 몇 개가 있어야 합니까?";
• «Kubernetes 보안의 ABC: 인증, 권한 부여, 감사";
• «Kubernetes의 자동 크기 조정 및 리소스 관리» (보고서 검토 및 비디오)
• «쿠버네티스의 ConfigMaps: 알아야 할 미묘한 차이점".

출처 : habr.com