cBSS前台子应用微服务的k8s初期搭建及准备工作

cBSS前台子应用微服务Kubernetes初期搭建全流程指南

本文基于某省级运营商核心业务系统（cBSS）前台子应用微服务容器化实践，详细解析Kubernetes 1.23生产集群搭建全流程，涵盖技术选型、环境规划及关键配置要点。

一、Kubernetes技术演进与选型依据

1. 容器技术演进时间轴

gantt title 容器技术演进关键节点 dateFormat YYYY section 技术演进 Docker开源 :2013, 3m Kubernetes诞生 :2014, 5m CRI标准化 :2016, 3m Containerd成熟 :2017, 2m Docker弃用 :2020, 3m section 行业应用运营商容器化试点 :2018, 12m cBSS微服务改造 :2021, 24m 生产级K8S集群上线 :2023, 12m

2. 版本选型决策树

graph TD A[是否需要Docker运行时] -->|是| B[选择1.23.x版本] A -->|否| C{选择标准} C -->|稳定性优先| D[LTS版本1.26+] C -->|功能需求| E[最新稳定版]

选型要点：

1.23.17特性：最后官方支持Docker的LTS版本
兼容性验证：通过CNCF一致性认证的发行版
补丁支持：安全更新支持至2025年

二、生产集群规划方案

1. 硬件资源配置矩阵

节点类型	数量	CPU	内存	存储	网络带宽
Master	3	64C	256G	4TB NVMe	25Gbps
Node	20	64C	128G	2TB SSD	10Gbps
etcd	5	32C	64G	1TB Optane	25Gbps

关键配置说明：

操作系统：UOSV20 1002a（等保三级认证）
存储架构：Ceph RBD + NVMeoF
网络拓扑：Spine-Leaf架构，BGP动态路由

2. 网络规划表

网络类型	网段规划	安全策略
节点管理网络	10.0.0.0/24	仅开放6443/2379/10250端口
Pod网络	10.100.0.0/16	Calico NetworkPolicy管控
Service网络	10.200.0.0/16	南北向流量通过API网关过滤
存储专用网络	192.168.100.0/24	独立物理网卡，iSCSI加密传输

三、集群部署技术选型

1. 部署方案对比矩阵

方案	适用场景	运维复杂度	扩展性	典型案例
二进制部署	深度定制环境	⭐⭐⭐⭐	高	金融核心系统
kubeadm	标准生产环境	⭐⭐	中	运营商业务系统
Kubesphere	可视化运维	⭐	低	中小企业
云托管服务	快速上云	⭐	自动扩展	互联网业务

选择kubeadm的依据：

符合运营商自主可控要求
支持与现有运维体系无缝集成
便于定制CSI/CNI插件

2. 关键组件版本清单

组件	版本	加固措施
Kubernetes	v1.23.17	启用PodSecurityPolicy
Docker	20.10.21	限制容器特权模式
Calico	v3.24.5	启用WireGuard加密
Ceph	16.2.11	启用RBD加密
Prometheus	v2.45.0	对接统一监控平台

四、集群初始化操作手册

1. 节点初始化脚本

#!/bin/bash
# 系统内核调优
cat > /etc/sysctl.d/k8s.conf <<EOF
net.ipv4.ip_forward = 1
net.bridge.bridge-nf-call-iptables = 1
fs.file-max=1000000
EOF
sysctl -p /etc/sysctl.d/k8s.conf

# 安装Docker运行时
yum install -y docker-ce-20.10.21
systemctl enable docker

# 配置Docker镜像加速
mkdir -p /etc/docker
cat > /etc/docker/daemon.json <<EOF
{
  "exec-opts": ["native.cgroupdriver=systemd"],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m"
  },
  "storage-driver": "overlay2"
}
EOF

2. kubeadm初始化配置

# kubeadm-config.yaml
apiVersion: kubeadm.k8s.io/v1beta3
kind: InitConfiguration
nodeRegistration:
  criSocket: unix:///var/run/dockershim.sock
---
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
kubernetesVersion: 1.23.17
networking:
  podSubnet: 10.100.0.0/16
  serviceSubnet: 10.200.0.0/16
apiServer:
  extraArgs:
    service-account-issuer: https://kubernetes.default.svc
    service-account-signing-key-file: /etc/kubernetes/pki/sa.key
controllerManager:
  extraArgs:
    node-cidr-mask-size: "24"
scheduler:
  extraArgs:
    bind-address: "0.0.0.0"

五、微服务部署规范

1. 典型Deployment配置

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cbs-frontend
  labels:
    app.ops/owner: "bss-team"
spec:
  replicas: 6
  strategy:
    rollingUpdate:
      maxSurge: 25%
      maxUnavailable: 10%
  selector:
    matchLabels:
      app: cbs-frontend
  template:
    metadata:
      labels:
        app: cbs-frontend
    spec:
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values: ["cbs-frontend"]
            topologyKey: "kubernetes.io/hostname"
      containers:
      - name: frontend
        image: registry.internal/cbss/frontend:v2.3.1
        resources:
          limits:
            cpu: "2"
            memory: 4Gi
          requests:
            cpu: "1"
            memory: 2Gi
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 15
          periodSeconds: 5

2. 服务暴露拓扑

graph LR A[客户端] --> B[NGINX Ingress] B --> C[cbs-frontend Service] C --> D[Pod Group 1] C --> E[Pod Group 2] D --> F[业务容器] E --> F F --> G[Redis Cluster] F --> H[MySQL Cluster]

六、运维监控体系

1. 监控指标看板

2. 关键告警规则

- alert: PodOOMKilled
  expr: sum(kube_pod_container_status_last_terminated_reason{reason="OOMKilled"}) by (pod) > 0
  for: 2m
  labels:
    severity: critical
  annotations:
    summary: "{{ $labels.pod }}发生内存溢出"

- alert: APILatencyHigh
  expr: histogram_quantile(0.99, sum(rate(apiserver_request_duration_seconds_bucket[5m])) by (le)) > 2
  for: 5m
  labels:
    severity: warning

总结

通过本文的体系化建设方案，某运营商cBSS系统成功实现：

业务连续性：99.99%的SLA保障
资源利用率：CPU利用率提升至65%
交付效率：版本发布时间从小时级缩短至分钟级

后续演进方向：

引入服务网格实现细粒度流量管理
构建多集群联邦提升容灾能力
推进Serverless化改造

作者：leo-zhang
版权声明：原创作品，谢绝转载！否则将追究法律责任。

posted on 2025-01-14 18:49 Leo_Yide 阅读(79) 评论(0) 收藏举报