Kubernetes: 오케스트레이터, 솔직하게 주장

핵심 내용

• 핵심 개체 모델은 정말 훌륭합니다. 배포는 원하는 복제본 상태를 설명하고 서비스는 안정적인 네트워킹을 제공하며 ConfigMap/Secrets는 별도의 구성을 제공하고 Ingress는 외부에 도달합니다. 선언적 조정(드리프트를 수정하는 컨트롤러)은 다른 모든 것이 구축되는 아키텍처입니다.
• 운영 가중치는 실제입니다. 제어 평면 구성 요소(API 서버, etcd, 스케줄러, 컨트롤러 관리자)에는 각각 HA 및 모니터링이 필요합니다. etcd 백업은 클러스터의 복구 가능 여부를 결정하는 흥미롭지 않은 단일 작업입니다. 업그레이드 규율(단계당 하나의 마이너 버전, 카나리아 노드 먼저)은 지속적인 의무입니다.
• 관리형 포크와 자체 관리형 포크: 운영 절감을 위한 GKE/EKS/AKS 거래 제어, k3s/microk8s는 소규모 플릿을 위한 합법적인 미니 배포판이며, 자체 관리형 HA 마스터는 대규모 팀 프로젝트로 남아 있습니다. 호스팅 비즈니스의 경우 소수의 노드에 있는 k3s가 종종 올바른 한도입니다.
• 스토리지는 대부분의 첫 번째 클러스터가 손상되는 부분입니다. 서로 다른 클라우드의 스토리지 클래스 전반에 걸쳐 PV/PVC가 다르고, HostPath는 발판이며, 블록 스토리지 지원 클래스에는 실제 IOPS/속도 의미가 있습니다. 첫 번째 상태 저장 워크로드 전에 스토리지 클래스 및 백업 전략(velero 클래스)을 계획합니다.
• 네트워킹은 자체 규율입니다. CNI 선택(플란넬, 옥양목, 실륨) 제어 오버레이와 기본 라우팅 및 송신 정책입니다. 수신(nginx/traefik) 및 인증서 관리자가 TLS를 처리합니다. 시장 도구는 게이트웨이 API 성숙도에 따라 다릅니다. 선택하기 전에 측정하십시오.
• 컨테이너 카테고리에 대한 정직한 평결은 다음과 같습니다. 다중 노드 예약, 자동 크기 조정 및 API 기반 배포 자동화가 워크로드를 수행할 때 Kubernetes를 채택합니다. 단일 WordPress 서버를 k8s하지 마십시오. k3s급 배포판은 유틸리티 영역을 확장하지만 가장 작고 정직한 클러스터는 여전히 Compose보다 더 많은 작업 비용을 발생시킵니다.

현장 노트

'Kubernetes가 필요한' 클라이언트는 2개의 호스트에 정확히 4개의 서비스가 필요한 것으로 밝혀졌고, k3s는 특권을 위해 제어 플레인을 제공했습니다. 우리는 그들을 일반 작성 스택으로 마이그레이션했고 통화 중 호출기가 조용해졌습니다. 최고의 Kubernetes 결정은 본인이 내리지 않은 결정인 경우가 많습니다.

자주 묻는 질문