技术和基础设施→ Kubernetes集群和Helm图表

Kubernetes群集和Helm图表

1）Kubernetes和Helm的角色

Kubernetes是应用程序平台的基础：标准化推出，网络，configs，秘密和自我修复。Helm是软件包/模板管理器，可将声明性清单转换为具有版本控制和依赖项的可重复版本。它们共同提供了可预测的解锁，快速回滚和统一的基础设施语言。

2）群集设计

2.1拓扑和容错性

Multi-AZ：控制平面和工作池节点分布在各个区域；PDB/TopologySpreadConstraints用于均匀性。
多区域/DR：独立区域集群；区域间呼叫-仅通过"冷"路径（目录/遥测），"热"（钱包）-本地。
按配置文件排列的工人池："general"、"compute"、"io"、"spot"（用于背景任务）。通过nodeSelector/affinity/taints进行分配。

2.2个命名空间和多用户模型

域名隔离："payments"，"wallet"，"games"，"reporting"。
ResourceQuota+LimitRange：基本的CPU/RAM限制和最大副本；保护群集免受"吸尘器"的影响。
RBAC：默认只读角色,write只是CI/CD和呼叫。

2.3个网络

支持NetworkPolicy（Calico/Cilium）的CNI：命名空间/标签策略L3/L4。
Ingress →Gateway API：过渡到"GatewayClass/Gateway/HTTPRoute"模型，用于加那利群岛和许多阴影。
Service Mesh（可选）：mTLS, retry/breaker, locality-aware；为服务间可靠性逐点启用。

3）可靠性和扩展

3.1 Skeiling

HPA按用户指标（RPS/latency/queue depth），而不仅仅是CPU。
背景载荷类上的VPA；在销售中-"仅回收"或与HPA一起使用不同的指标。
Cluster Autoscaler：针对敏感服务的单独节点组；warm-pool to peeks（锦标赛/比赛）。

3.2资源和QoS

每个Pod都具有要求/限制；避免"：最新"和"无限制"容器。
PriorityClass：关键服务（"wallet","payments"）取代非关键服务。
PDB：我们不要在更新脚注时给群集"射击自己"。

3.3次升级无停机

RollingUpdate c maxUnavailable=0在关键路径上。

PodDisruptionBudget + ReadinessProbes (не `startupProbe` вместо readiness).

在峰值期间快速发布的surge容量-谨慎。

4）平台安全

Namespace级别的Pod Security（基线/限制）；禁止"特权"，hostPath，root。
NetworkPolicy：默认值和按端口/标签列出的白色列表。

Seccomp/AppArmor, non-root users, read-only rootfs.

秘密：KMS/Vault提供商（CSI），在"价值"中不保留秘密。yaml'公开形式。
RBAC最低：服务帐户仅授予必要的权利；令牌寿命短。
管理控制：OPA/Gatekeeper/Kyverno-标签，限制，策略违规的执法。

5) Observability

OpenTelemetry：来自Ingress/Gateway的跟踪→服务→ DB/缓存，强制性标签"服务"，"版本"，"区域"，"合作伙伴"，"api_version"。
Logs：结构化，没有PII/PAN；路由到集中存储。
度量：RED/USE，SLO-dashbords，burn-rate alerta。
合成：来自所需国家/ASN的样品；外围和内部健康检查。

6) GitOps и progressive delivery

Argo CD/Flux：理想状态存储在Git中；每个namespace是其自己的存储库/文件夹。
文物的推广：通过PR而不是"kubectl apply"的"dev stage prod"。
Canary/Blue-Green: Argo Rollouts/Gateway API;成功指标是P95/P99、错误率、业务SLI（存款的CR）。
回滚：在Helm/Argo中-按按钮；在图表中-版本是固定的。

7） Helm： 最佳实践

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"是应用程序（图像）的版本。
• 严格的资源名：'{include' svc。fullname".}}"+标签"应用程序。kubernetes.io/`.
• 强制性宣言：发布/StatefulSet，服务，ServiceAccount，HPA（如果适用），PDB，NetworkPolicy。

7.2 Values策略

基本的价值。yaml'-默认,没有秘密或环境细节。
覆盖："values-{stage'prod} .yaml"+per-region文件。
秘密：SOPS（"价值证明。sops.yaml'）或通过CSI进行保险库注射。
资源和样本参数以"合理"默认值为单位。

7.3依存关系和共享代码

模式的通用图表库（probes，annotations，NetworkPolicy）。
相关性（"要求"/"图表。yaml'）根据版本固定；避免深层的"床垫"。

7.4模板和检查

在'_helpers中使用'required'和'fail'。tpl'表示临界值。

Values方案的验证是'values。schema.json`.

图表的统一测试是"helm unittest"；静态分析-kubeconform/kubeval。
本地调试是"helm template"+"-values"+"kubeconform"。

7.5个版本和存储

在OCI容器寄存器中绘制图表；SemVer标签。
Helmfile/`helmfile.d'用于编排多项式展开。
CI工件：生成的清单+lockfile依存关系。

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）秘密和配置

通过CSI （Vault/KMS）或Git存储库中的SOPS （GPG/KMS；禁止"kubectl edit"）。
用于滚动发布触发器的ConfigMap/Secret checksum注释。
不存储PAN/PII；使用令牌化。
允许播种秘密，但最好是SOPS或直接CSI。

10）网络和外围

用于L7路由，金丝雀和蓝绿色的Gateway API；sticky会话仅在必要时进行。
通过mesh/sidecar-less（Cilium）在服务之间的mTLS是支付核心的点。
Egress：受控的外部节点列表（PSP/KYC），固定NAT-IP，定时和撤退预算。

11） Stateful服务和数据

对于OLTP-DBD,在单独的群集中使用托管云服务或运算符（Postgres/MySQL）。
PVC/CSI具有snapshot和backaps策略；复制的"PodAntiAffinity"。
对于队列/流媒体-托管解决方案或专用群集；在"一般"应用群集中保持最低状态。

12） CI/CD输送机（参考）

1.构建和测试→ 2） SCA/lint → 3）寄存器映像（SBOM,签名）→

2.Helm图表生成+'helm unittest'+kubeconform →

3.Rantime CD → 6）PR中的SOPS剪辑到GitOps存储库→

4.Argo/Flux应用→ 8） Argo Rollouts金丝雀→ 9） SLO自动判决→ 10）推广/回滚。

13）平台成熟度量标准

通过GitOps发布的份额（目标：100％）。
在准备就绪之前的滚动时间（P95），MTTR回滚。
Namespace的Pod Security和NetworkPolicy覆盖范围（目标：100％）。
具有HPA和正确请求/限制的服务百分比。
具有'values的图表百分比。schema.json'和unit测试。
由"手动"更改引起的事件（目标：0）。

14）实施支票

1.区域群集，配置文件节点池；PDB/TopologySpreadConstraints.

2.Namespace模型，ResourceQuota/LimitRange，RBAC最小值。

3.Pod Security (Restricted) и default-deny NetworkPolicy.

4.Gateway API/Ingress;egress控制和NAT提交给提供商。
5.观察力：OTel步道，RED/USE，地质合成器；SLO-dashbords。
6.GitOps（Argo/Flux），金丝雀/蓝绿色，按度量划分的汽车行业。
7.Helm标准：结构，计划。json，测试，SOPS/Vault，OCI寄存器。
8.HPA/VPA、Cluster Autoscaler、warm-pool to peaks。
9.数据操作：CSI狙击，备份，运算符/托管DB。
10.定期DR/混沌测试和游戏日。

15）反模式

一个没有隔离和配额的"巨型"集群。
没有资源限制的容器，"最新"标签，没有问题。
"价值"中的秘密。yaml'公开形式，'kubectl edit'在销售中。
通过GitOps的版本，对实时群集上的清单进行手动编辑。
没有NetworkPolicy/Pod Security是"扁平"网络。
CPU上用于不同类型负载的单个HPA通用信号。
将OLTP-DB存储在"共享"应用程序群集中，而无需运算符和后备程序。

16） iGaming/fintech上下文： 实用音符

付费webhooks：专用的ingress/gateway和狭窄的PSP egress；严格的taymauts/retrai；一个单独的节点池。
VIP流量：优先级和个别路线；PDB和topology spread用于稳定性。
比赛/高峰：warm-pool节点+谓词HPA；加热缓存/连接。
报告/CDC：单独的群集/池，以便ETL不会影响prod。

调节： 不变逻辑（WORM）, PII令牌化,网络分割.

底线

强大的Kubernetes平台不是"一堆YAML"，而是标准：隔离、安全政策、管理资源、可观察性和GitOps纪律。Helm图表是您的交付合同：可预测的版本，可测试的模板，安全的秘密操作以及简单的回滚。通过巩固这些原则，您可以获得能够达到峰值，加快发布速度并满足业务和监管机构要求的群集。