기술 및 인프라 → Kubernetes 클러스터 및 헬름 차트
Kubernetes 클러스터 및 헬름 차트
1) Kubernetes와 Helm의 역할
Kubernetes는 응용 플랫폼의 기초입니다. 롤링, 네트워킹, 구성, 비밀 및 자기 치유를 표준화합니다. Helm은 선언적 표현을 버전 제어 및 종속성을 갖춘 반복 가능한 릴리스로 바꾸는 패키지/템플릿 관리자입니다. 이들은 함께 예측 가능한 파견, 빠른 롤백 및 단일 인프라 언어를 제공합니다.
2) 클러스터 디자인
2. 1 토폴로지 및 내결함 내성
다중 AZ: 제어 평면 및 작업자 풀 노드가 구역화되어 있습니다. 균일 성을위한 PDB/TopologySpreadConstrints.
다중 지역/DR: 독립적 인 지역 별 클러스터; "콜드" 경로 (디렉토리/원격 측정), "핫" (지갑) 에서만 로컬 간 통화.
프로필 별 작업자 풀: '일반', '계산', 'io', '스팟' (배경 작업). nodeSelector/proficition/tains를 통한 할당.
2. 네임 스페이스 및 다중 사용자 모델 2 개
도메인/명령에 의한 공백 격리: '결제', '지갑', '게임', '보고'.
ResourceQuota + LimitRange: 기본 CPU/RAM 제한 및 최대 복제본; "진공 청소기" 에 대한 클러스터 보호.
RBAC: 기본적으로 읽기 전용 역할, 쓰기 - CI/CD 및 통화 중.
2. 3 네트워크
NetworkPolicy 지원이있는 CNI (Calico/Cilium): 네임 스페이스/레이블에 의하여 정책 L3/L4.
Ingress → Gateway API: 카나리아 및 다중 임차를 위해 'GatewayClass/Gateway/HTTPRoute' 모델로 전환하십시오.
서비스 메시 (옵션): mSL, 재 시도/차단기, 지역 인식; 서비스 간 신뢰성을 위해 포인트를 켜십시오.
3) 신뢰성 및 확장 성
3. 1 스케일링
CPU뿐만 아니라 사용자 지표 (RPS/대기 시간/큐 깊이) 별 HPA.
배경로드 클래스의 VPA; 제품에서 - "권장 사항 만" 또는 다른 지표에서 HPA와 함께.
클러스터 오토 스케일러: 민감한 서비스를위한 별도의 노드 그룹; 따뜻한 풀 선택 (토너먼트/경기).
3. 2 개의 리소스 및 QoS
각 포드에는 요청/제한이 있습니다. ': 최신' 및 '무제한' 컨테이너를 피하십시오.
PriorityClass: 중요한 서비스 ('지갑', '지불') 는 중요하지 않은 서비스를 대체합니다.
PDB: 노드를 업데이트 할 때 클러스터가 "발로 쏘지" 않도록하십시오.
3. 다운 타임없이 3 업그레이드
임계 경로에서 maxUnasable = 0으로 롤링 업데이트.
PodDisruptionBudget + ReadinessProbes (н릴리스 'startupProbe'
정점 동안 빠른 방출을위한 급증 용량-주의해서.
4) 플랫폼 보안
네임 스페이스 수준의 포드 보안 (Baseline/Restricted); '특권' 허용 불가, 호스트 경로, 뿌리.
네트워크 정책: 포트/라벨별로 기본 거부 및 화이트 리스팅.
루트가 아닌 사용자 인 Seccomp/AppArmor는 읽기 전용 루트입니다.
비밀: KMS/Vault 제공 업체 (CSI) 는 비밀을 '값에 유지하지 않습니다. 열린 형태의 yaml.
RBAC 최소: 필요한 권리 만 서비스 계정을 발행합니다. 수명이 짧은 토큰.
입학 통제: OPA/Gatekeeper/Kyverno-레이블, 제한, 정책 위반을 시행합니다.
5) 관찰 가능성
OpenTelemetry: Ingress/Gateway → 서비스 → 데이터베이스/캐시, 필수 레이블 '서비스', '버전', '지역', '파트너', 'api _ 버전' 에서 추적.
로그: 구조화 된 PII/PAN 없음; 중앙 집중식 스토리지로 라우팅
지표: RED/USE, SLO 대시 보드, 연소율 경고.
합성: 올바른 국가/ASN의 샘플; 주변 및 내부 건강 검진.
6) GitOps! 프로그레시브 전달
Argo CD/Flux: 원하는 상태는 Git에 저장됩니다. 각 네임 스페이스에는 고유 한 저장소/폴더가 있습니
아티팩트 홍보: "kubectl 적용" 이 아닌 PR을 통한 'dev→ stage → prod'.
카나리아/블루-그린: 아르고 롤 아웃/게이트웨이 API; 성공 지표-P95/P99, 오류율, 비즈니스 SLI (예금 CR).
롤백: Helm/Argo-버튼 별; 차트에서-버전이 수정되었습니다.
7) 투구: 모범 사례
7. 1 차트 구조
my-service/
Chart. yaml # name, version (SemVer), appVersion values. yaml # base values (no secrets)
values-prod. yaml # prod overrides (no secrets)
templates/
_helpers. tpl # naming, common deployment templates. yaml service. yaml hpa. yaml pdb. yaml networkpolicy. yaml serviceaccount. yaml ingress_or_gateway. yaml charts/# dependencies (opcional)- '버전' - 차트 버전 (SemVer), 'appVersion' - 응용 프로그램 (이미지) 버전.
- 강력한 리소스 이름은 '{{poto' svc입니다. 전체 이름. "}} '+ 라벨' app. kubernetes. 이오/'.
- 필요한 표시: 배포/상태 설정, 서비스, 서비스 계정, HPA (해당되는 경우), PDB, 네트워크 정책.
7. 2 가치 전략
기본 가치. yaml '- 비밀과 환경 특성이없는 기본값.
오버 라이드: 'values- {stage' prod} .yaml '+ 지역 당 파일.
비밀: SOPS ('값-prod. sops. yaml ') 또는 CSI를 통한 Vault 주입.
"합리적인" 불이행 값의 리소스 및 샘플 매개 변수.
7. 3 의존성 및 공통 코드
패턴 (프로브, 주석, 네트워크 정책) 에 대한 일반적인 차트 라이브러리.
의존성 ('요구 사항 '/' 차트. yaml ') 버전별로 수정; 깊은 "중첩 인형" 을 피하십시오.
7. 4 개의 템플릿 및 검사
(PHP 3 = 3.0.6, PHP 4) 임계 값의 tpl '.
값- '값 체계의 검증. 스키마. json '.
단위 차트 테스트- 'helm unittest'; 정적 분석-kubecomper/kubeval.
로컬 디버깅- 'helm 템플릿' + '-값' + 'kubecomple'.
7. 5 릴리스 및 스토리지
차트를 OCI 컨테이너 레지스터로 푸시하십시오. SemVer의 태그.
헬름 파일/' 헬름 파일. 다중 차트 시브의 오케스트레이션.
CI 아티팩트: 생성 된 표현식 + 잠금 파일 종속성.
8) 예: 배포 (Helm 템플릿 조각)
yaml apiVersion: apps/v1 kind: Deployment metadata:
name: {{ include "svc. fullname". }}
labels: {{ include "svc. labels". nindent 4 }}
spec:
replicas: {{.Values. replicas default 3 }}
strategy:
type: RollingUpdate rollingUpdate:
maxSurge: 1 maxUnavailable: 0 selector:
matchLabels: {{ include "svc. selectorLabels". nindent 6 }}
template:
metadata:
labels: {{ include "svc. selectorLabels". nindent 8 }}
annotations:
checksum/config: {{ include (print $.Template. BasePath "/configmap. yaml"). sha256sum }}
spec:
serviceAccountName: {{ include "svc. serviceAccountName". }}
securityContext:
runAsNonRoot: true containers:
- name: app image: "{{.Values. image. repository }}:{{.Values. image. tag }}"
imagePullPolicy: IfNotPresent ports:
- name: http containerPort: {{.Values. ports. http }}
resources:
requests:
cpu: {{.Values. resources. requests. cpu }}
memory: {{.Values. resources. requests. memory }}
limits:
cpu: {{.Values. resources. limits. cpu }}
memory: {{.Values. resources. limits. memory }}
readinessProbe:
httpGet:
path: /healthz port: http periodSeconds: 5 envFrom:
- secretRef:
name: {{ include "svc. secretsName". }}9) 비밀과 구성
Git 저장소의 CSI (Vault/KMS) 또는 SOPS를 통한 비밀 (Git/KMS 키); 'kubectl 편집' 은 금지되어 있습니다).
릴리스 트리거를위한 ConfigMap/Secret 체크섬 주석.
PAN/PII를 저장하지 마십시오. 토큰 화 사용.
밀봉 된 비밀은 허용되지만 SOPS 또는 직접 CSI가 선호됩니다.
10) 네트워크 및 주변
L7 라우팅, 카나리아 및 청록색을위한 게이트웨이 API; 필요한 경우에만 끈적 끈적한 세션.
메쉬/사이드카리스 (실륨) 를 통한 서비스 간 mTLS-결제 코어를 가리 킵니다.
탈출: 제어 된 외부 노드 목록 (PSP/KYC), 고정 된 GPS-IP, 타임 아웃 및 재 트레이 예산.
11) 안정적인 서비스 및 데이터
OLTP 데이터베이스의 경우 별도의 클러스터에서 관리되는 클라우드 서비스 또는 운영자 (Postgres/MySQL) 를 사용하십시오.
스냅 샷 및 백업 정책이있는 PVC/CSI; 복제품을위한 'PodAntiAffinity'.
대기열/스트리밍-관리 솔루션 또는 전용 클러스터; "공통" 응용 프로그램 클러스터에서 최소 상태를 유지하십시오.
12) CI/CD 컨베이어 (참조)
1. 빌드 및 테스트 → 2) SCA/린트 → 3) 레지스터의 이미지 (SBOM, 서명) →
2. Helm 차트 생성 + 'helm unittest' + kubecomper →
3. CD → 6) GitOps 저장소의 PR 런타임 →
4. Argo/Flux 적용 → 8) Argo Rollout 카나리아 → 9) SLO Auto Verdict → 10) 프로모션/롤백.
13) 플랫폼 성숙도 지표
GitOps를 통한 릴리스 공유 (대상: 100%).
준비 될 때까지 롤링 시간 (P95), MTTR 롤백.
Namespace Pod 보안 및 네트워크 정책의 적용 범위 (대상: 100%).
HPA 및 정확한 요청/제한이있는 서비스의%.
'값이있는% 차트. 스키마. json 'and 단위 테스트.
"수동" 변경으로 인한 사고 (대상: 0).
14) 구현 점검표
1. 구역 별 클러스터, 프로파일 별 노드 풀; PDB/TopologySpreadConstraints.
2. Namespace 모델, ResourceQuota/LimitRange, RBAC 최소.
3. 포드 보안 (제한됨) 은 기본 거부 네트워크 정책입니다.
4. 게이트웨이 API/Ingress; 공급자에 대한 출구 제어 및 NAT 고정.
5. 관찰 가능성: OTel 트레일, RED/USE, 지리 합성; SLO 대시 보드.
6. GitOps (Argo/Flux), 카나리아/청록색, 지표 별 자동 프로모션.
7. 헬름 표준: 구조, 스키마. json, 테스트, SOPS/Vault, OCI 레지스터.
8. HPA/VPA, Cluster Autoscaler, 따뜻한 수영장 대 봉우리.
9. 데이터 작업: CSI 스냅 샷, 백업/관리 데이터베이스 운영자.
10. 정기적 인 DR/혼돈 테스트 및 게임 일.
15) 반 패턴
격리와 할당량이없는 모든 것을위한 하나의 "거대한" 클러스터.
자원 제한이없는 컨테이너, '최신' 태그, 프로브 없음.
가치의 비밀. 명확한 텍스트의 yaml, prod의 'kubectl 편집'
GitOps를 통해 릴리스, 라이브 클러스터에서 수동 매니페스트 편집.
NetworkPolicy/Pod Security 부족- "평면" 네트워크.
다른 유형의로드에 대한 CPU의 단일 공통 HPA 신호.
연산자와 백업이없는 "공통" 응용 프로그램 클러스터 내에 OLTP 데이터베이스 저장.
16) iGaming 컨텍스트/핀 테크: 실제 노트
결제 웹 후크: 전용 진입/게이트웨이 및 PSP로의 좁은 출구; 엄격한 타임 아웃/리트레이; 개별 호스트 풀.
VIP 트래픽: 우선 순위 및 개별 경로; 안정성을 위해 PDB 및 토폴로지가 확산되었습니다.
토너먼트/픽: 따뜻한 풀 노드 + 예측 HPA; 캐시/연결 예열.
보고/CDC: ETL이 Prod에 영향을 미치지 않도록 별도의 클러스터/풀.
규제: 불변의 통나무 (WORM), PII 토큰 화, 네트워크 세분화.
합계
강력한 Kubernetes 플랫폼은 "YAML 힙합" 이 아니라 격리, 보안 정책, 관리 리소스, 관찰 가능성 및 GitOps 분야와 같은 표준입니다. 헬름 차트-공급 계약: 예측 가능한 릴리스, 테스트 가능한 패턴, 보안 비밀 취급 및 간단한 킥백. 이러한 원칙을 통합함으로써 정점에서 살아남고 릴리스를 가속화하며 비즈니스 및 규제 요구를 견딜 수있는 클러스터를 얻을 수 있습니다.