Kubernetes에 첫 번째 애플리케이션을 배포할 때 다섯 가지 실수

Aris Dreamer의 실패

많은 사람들은 애플리케이션을 Kubernetes로 전송하는 것으로 충분하다고 생각합니다(Helm을 사용하거나 수동으로). 그러나 모든 것이 그렇게 간단하지는 않습니다.

팀 Mail.ru 클라우드 솔루션 DevOps 엔지니어 Julian Gindy의 기사를 번역했습니다. 그는 이전 과정에서 자신의 회사가 어떤 함정에 빠졌는지 알려줍니다. 그래서 같은 갈퀴를 밟지 않도록 합니다.

XNUMX단계: Pod 요청 및 제한 설정

포드가 실행될 깨끗한 환경을 설정하는 것으로 시작하겠습니다. Kubernetes는 팟(Pod) 스케줄링 및 장애 조치(failover)에 탁월합니다. 그러나 성공적으로 작동하는 데 필요한 리소스 수를 추정하기 어려운 경우 스케줄러가 포드를 배치할 수 없는 경우가 있는 것으로 나타났습니다. 리소스 및 제한에 대한 요청이 팝업되는 곳입니다. 요청 및 제한 설정에 대한 최선의 접근 방식에 대해 많은 논쟁이 있습니다. 때때로 이것은 과학보다 예술에 더 가깝습니다. 여기에 우리의 접근 방식이 있습니다.

포드 요청 Pod를 최적으로 배치하기 위해 스케줄러에서 사용하는 기본 값입니다.

으로 쿠버네티스 문서: 필터 단계는 Pod를 예약할 수 있는 노드 집합을 정의합니다. 예를 들어 PodFitsResources 필터는 포드의 특정 리소스 요청을 충족하기에 충분한 리소스가 노드에 있는지 확인합니다.

우리는 얼마나 많은 리소스를 추정할 수 있는 방식으로 애플리케이션 요청을 사용합니다. 사실 응용 프로그램이 제대로 작동하려면 필요합니다. 이렇게 하면 스케줄러가 실제로 노드를 배치할 수 있습니다. 처음에는 각 포드에 충분한 리소스를 확보하기 위해 요청을 과도하게 예약하려고 했지만 예약 시간이 크게 증가했고 일부 포드는 리소스 요청이 없는 것처럼 완전히 예약되지 않았습니다.

이 경우 스케줄러는 종종 포드를 "압축"하고 제어 평면이 애플리케이션에 필요한 리소스의 양을 모르기 때문에 포드를 다시 예약할 수 없습니다. 이는 스케줄링 알고리즘의 핵심 구성 요소입니다.

포드 한도 포드에 대한 명확한 제한입니다. 클러스터가 컨테이너에 할당할 최대 리소스 양을 나타냅니다.

다시 말하지만 공식 문서: 컨테이너의 메모리 제한이 4GiB이면 kubelet(및 컨테이너 런타임)이 이를 적용합니다. 런타임은 컨테이너가 지정된 리소스 한도 이상을 사용하지 못하도록 합니다. 예를 들어 컨테이너의 프로세스가 허용된 메모리 양보다 더 많이 사용하려고 하면 시스템 커널이 "메모리 부족"(OOM) 오류와 함께 프로세스를 종료합니다.

컨테이너는 항상 리소스 요청이 지정하는 것보다 더 많은 리소스를 사용할 수 있지만 한도를 초과하여 사용할 수는 없습니다. 이 값은 올바르게 설정하기 어렵지만 매우 중요합니다.

이상적으로는 시스템의 다른 프로세스를 방해하지 않고 프로세스의 수명 주기 동안 포드의 리소스 요구 사항이 변경되기를 원합니다. 이것이 제한을 설정하는 목적입니다.

안타깝게도 설정할 값에 대한 구체적인 지침을 제공할 수는 없지만 다음 규칙을 준수합니다.

1. 부하 테스트 도구를 사용하여 트래픽의 기본 수준을 시뮬레이션하고 포드 리소스(메모리 및 프로세서)의 사용을 관찰합니다.
2. Pod 요청을 임의로 낮은 값(요청 값의 약 5배 리소스 제한)으로 설정하고 관찰합니다. 요청 수준이 너무 낮으면 프로세스를 시작할 수 없어 종종 수수께끼 같은 Go 런타임 오류가 발생합니다.

포드에는 사용 가능한 리소스가 충분한 대상 노드가 필요하기 때문에 리소스 제한이 높을수록 예약이 더 어려워집니다.

4GB 메모리와 같이 리소스 제한이 매우 높은 경량 웹 서버가 있는 상황을 상상해 보십시오. 이 프로세스는 수평으로 확장해야 할 가능성이 높으며 각각의 새 포드는 사용 가능한 메모리가 4GB 이상인 노드에서 예약해야 합니다. 그러한 노드가 없으면 클러스터는 이 포드를 처리하기 위해 새 노드를 도입해야 하며 이는 다소 시간이 걸릴 수 있습니다. 빠르고 원활한 확장을 보장하기 위해 리소스 요청과 제한 간의 차이를 최소화하는 것이 중요합니다.

XNUMX단계: 활성 및 준비 테스트 설정

이것은 Kubernetes 커뮤니티에서 자주 논의되는 또 다른 미묘한 주제입니다. Liveness 및 Readiness 테스트는 소프트웨어의 안정적인 작동을 위한 메커니즘을 제공하고 다운타임을 최소화하므로 이를 잘 이해하는 것이 중요합니다. 그러나 올바르게 구성하지 않으면 애플리케이션 성능에 심각한 영향을 미칠 수 있습니다. 다음은 두 샘플이 무엇인지 요약한 것입니다.

생동감 컨테이너가 실행 중인지 보여줍니다. 실패하면 kubelet이 컨테이너를 종료하고 다시 시작 정책이 활성화됩니다. 컨테이너에 Liveness Probe가 장착되지 않은 경우 기본 상태는 성공입니다. 쿠버네티스 문서.

활성 프로브는 저렴해야 합니다. 즉, 자주 실행되고 애플리케이션이 실행 중임을 Kubernetes에 알려야 하기 때문에 많은 리소스를 소비하지 않아야 합니다.

1초마다 실행하도록 옵션을 설정하면 초당 XNUMX개의 요청이 추가되므로 이 트래픽을 처리하려면 추가 리소스가 필요합니다.

당사에서 Liveness 테스트는 데이터(예: 원격 데이터베이스 또는 캐시의 데이터)를 완전히 사용할 수 없는 경우에도 애플리케이션의 핵심 구성 요소를 테스트합니다.

단순히 200 응답 코드를 반환하는 애플리케이션에 "상태" 엔드포인트를 설정했습니다. 이는 프로세스가 실행 중이고 요청을 처리할 수 있음을 나타내는 지표입니다(아직 트래픽은 아님).

샘플 준비 컨테이너가 요청을 처리할 준비가 되었는지 여부를 나타냅니다. 준비 프로브가 실패하면 엔드포인트 컨트롤러는 포드와 일치하는 모든 서비스의 엔드포인트에서 포드의 IP 주소를 제거합니다. 이는 Kubernetes 설명서에도 명시되어 있습니다.

준비 상태 프로브는 애플리케이션이 요청을 수락할 준비가 되었음을 표시하는 방식으로 백엔드에 도달해야 하므로 더 많은 리소스를 소비합니다.

데이터베이스에 직접 액세스할지 여부에 대해 커뮤니티에서 많은 논쟁이 있습니다. 오버헤드(검사는 빈번하지만 제어할 수 있음)를 고려하여 일부 애플리케이션의 경우 데이터베이스에서 레코드가 반환되는지 확인한 후에만 트래픽 처리 준비를 계산하기로 결정했습니다. 잘 설계된 준비 평가판은 더 높은 수준의 가용성을 보장하고 배포 중 다운타임을 없앴습니다.

애플리케이션의 준비 상태를 테스트하기 위해 데이터베이스를 쿼리하기로 결정한 경우 가능한 한 저렴한지 확인하십시오. 다음 쿼리를 살펴보겠습니다.

SELECT small_item FROM table LIMIT 1

다음은 Kubernetes에서 이 두 값을 구성하는 방법의 예입니다.

livenessProbe: 
 httpGet:   
   path: /api/liveness    
   port: http 
readinessProbe:  
 httpGet:    
   path: /api/readiness    
   port: http  periodSeconds: 2

몇 가지 추가 구성 옵션을 추가할 수 있습니다.

• initialDelaySeconds - 컨테이너 시작과 프로브 시작 사이에 경과할 시간(초)입니다.
• periodSeconds - 샘플 실행 사이의 대기 간격.
• timeoutSeconds — 포드가 비상 상태로 간주되는 시간(초)입니다. 정상적인 시간 초과.
• failureThreshold 재시작 신호가 팟(Pod)으로 전송되기 전에 테스트 실패 횟수입니다.
• successThreshold Pod가 준비 상태로 전환되기 전(Pod가 시작되거나 복구될 때 실패 후) 성공적인 시도 횟수입니다.

XNUMX단계: 포드의 기본 네트워크 정책 설정

Kubernetes에는 기본적으로 모든 포드가 서로 직접 통신하는 "플랫" 네트워크 지형이 있습니다. 어떤 경우에는 이것이 바람직하지 않습니다.

잠재적인 보안 문제는 공격자가 취약한 단일 애플리케이션을 사용하여 네트워크의 모든 포드에 트래픽을 보낼 수 있다는 것입니다. 많은 보안 영역에서와 마찬가지로 최소 권한 원칙이 여기에 적용됩니다. 이상적으로 네트워크 정책은 포드 간의 허용되는 연결과 허용되지 않는 연결을 명시적으로 명시해야 합니다.

예를 들어 다음은 특정 네임스페이스에 대한 모든 수신 트래픽을 거부하는 간단한 정책입니다.

---
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:  
 name: default-deny-ingress
spec:  
 podSelector: {}  
 policyTypes:  
   - Ingress

이 구성의 시각화:

(https://miro.medium.com/max/875/1*-eiVw43azgzYzyN1th7cZg.gif)
세부 정보 여기에.

XNUMX단계: 후크 및 초기화 컨테이너를 사용한 사용자 지정 동작

우리의 주요 목표 중 하나는 개발자를 위한 중단 시간 없이 Kubernetes에 배포를 제공하는 것이었습니다. 애플리케이션을 종료하고 사용된 리소스를 해제하는 옵션이 많기 때문에 이는 어렵습니다.

특히 어려움이 발생했습니다. Nginx에. 이러한 Pod를 순서대로 배포할 때 성공적으로 완료되기 전에 활성 연결이 중단되는 것을 확인했습니다.

인터넷에 대한 광범위한 연구 끝에 Kubernetes는 포드를 종료하기 전에 Nginx 연결이 소진될 때까지 기다리지 않는다는 것이 밝혀졌습니다. 사전 중지 후크의 도움으로 다음 기능을 구현하고 중단 시간을 완전히 제거했습니다.

lifecycle: 
 preStop:
   exec:
     command: ["/usr/local/bin/nginx-killer.sh"]

하지만 nginx-killer.sh:

#!/bin/bash
sleep 3
PID=$(cat /run/nginx.pid)
nginx -s quit
while [ -d /proc/$PID ]; do
   echo "Waiting while shutting down nginx..."
   sleep 10
done

매우 유용한 또 다른 패러다임은 초기화 컨테이너를 사용하여 특정 응용 프로그램의 실행을 처리하는 것입니다. 이는 응용 프로그램이 시작되기 전에 실행해야 하는 리소스 집약적인 데이터베이스 마이그레이션 프로세스가 있는 경우에 특히 유용합니다. 기본 응용 프로그램에 대해 이러한 제한을 설정하지 않고 이 프로세스에 대해 더 높은 리소스 제한을 지정할 수도 있습니다.

또 다른 일반적인 체계는 기본 모듈에 이러한 자격 증명을 제공하는 init 컨테이너의 비밀에 액세스하여 기본 애플리케이션 모듈 자체에서 비밀에 대한 무단 액세스를 방지하는 것입니다.

평소와 같이 문서에서 인용: 초기화 컨테이너는 애플리케이션 컨테이너 이미지의 보안을 손상시킬 수 있는 사용자 코드 또는 유틸리티를 안전하게 실행합니다. 불필요한 도구를 분리하여 애플리케이션 컨테이너 이미지의 공격 표면을 제한합니다.

XNUMX단계: 커널 구성

마지막으로 고급 기술에 대해 이야기해 보겠습니다.

Kubernetes는 적합하다고 판단되는 워크로드를 실행할 수 있는 매우 유연한 플랫폼입니다. 리소스를 많이 사용하는 고효율 애플리케이션이 많이 있습니다. 광범위한 로드 테스트를 수행한 후 기본 Kubernetes 설정이 적용될 때 애플리케이션 중 하나가 예상되는 트래픽 로드를 따라잡는 데 어려움을 겪고 있음을 발견했습니다.

그러나 Kubernetes를 사용하면 특정 포드에 대한 커널 매개변수만 변경하는 권한 있는 컨테이너를 실행할 수 있습니다. 열린 연결의 최대 수를 변경하는 데 사용한 방법은 다음과 같습니다.

initContainers:
  - name: sysctl
     image: alpine:3.10
     securityContext:
         privileged: true
      command: ['sh', '-c', "sysctl -w net.core.somaxconn=32768"]

이것은 종종 필요하지 않은 고급 기술입니다. 그러나 애플리케이션이 과도한 로드를 처리하는 데 어려움을 겪고 있다면 이러한 설정 중 일부를 조정할 수 있습니다. 이 프로세스에 대한 추가 정보 및 다른 값 설정 - 항상 그렇듯이 공식 문서에서.

결론적으로

Kubernetes가 즉시 사용 가능한 솔루션처럼 보일 수 있지만 애플리케이션을 원활하게 실행하기 위해 수행해야 하는 몇 가지 주요 단계가 있습니다.

Kubernetes로 마이그레이션하는 동안 "부하 테스트 주기"를 따르는 것이 중요합니다. 즉, 애플리케이션을 실행하고, 부하 상태에서 테스트하고, 메트릭 및 확장 동작을 관찰하고, 이 데이터를 기반으로 구성을 조정한 다음, 이 주기를 다시 반복합니다.

예상되는 트래픽에 대해 현실적으로 생각하고 어떤 구성 요소가 먼저 중단되는지 확인하기 위해 그 이상을 시도하십시오. 이 반복적인 접근 방식을 사용하면 나열된 권장 사항 중 몇 가지만으로도 성공을 거두기에 충분할 수 있습니다. 또는 보다 심층적인 사용자 지정이 필요할 수 있습니다.

항상 스스로에게 다음과 같은 질문을 하십시오.

1. 애플리케이션이 소비하는 리소스의 양은 얼마이며 이 양은 어떻게 변할까요?
2. 실제 확장 요구 사항은 무엇입니까? 앱이 평균적으로 얼마나 많은 트래픽을 처리합니까? 최대 트래픽은 어떻습니까?
3. 서비스를 얼마나 자주 확장해야 합니까? 트래픽을 수신하려면 새 팟(Pod)을 얼마나 빨리 시작하고 실행해야 합니까?
4. 포드는 얼마나 정상적으로 종료되나요? 전혀 필요합니까? 다운타임 없이 배포할 수 있습니까?
5. 보안 위험을 최소화하고 손상된 팟(Pod)의 손상을 제한하는 방법은 무엇입니까? 서비스에 필요하지 않은 권한이나 액세스 권한이 있습니까?

Kubernetes는 모범 사례를 사용하여 클러스터에 수천 개의 서비스를 배포할 수 있는 놀라운 플랫폼을 제공합니다. 그러나 모든 응용 프로그램은 다릅니다. 때로는 구현에 조금 더 많은 작업이 필요합니다.

다행스럽게도 Kubernetes는 모든 기술적 목표를 달성하는 데 필요한 설정을 제공합니다. 리소스 요청 및 제한, 활성 및 준비 프로브, 초기화 컨테이너, 네트워크 정책 및 사용자 지정 커널 튜닝의 조합을 사용하여 내결함성 및 빠른 확장성과 함께 고성능을 달성할 수 있습니다.

그 밖에 읽을 내용:

1. 프로덕션 환경에서 컨테이너 및 Kubernetes를 실행하기 위한 모범 사례 및 모범 사례.
2. Kubernetes를 위한 90개 이상의 유용한 도구: 배포, 관리, 모니터링, 보안 등.
3. Telegram의 Kubernetes 주변 채널.

출처 : habr.com