在 Kubernetes 上编排 MongoDB 集群

soft_007

发布于 2022-5-9 14:26

浏览

0收藏

作者 |阳明
来源 | k8s技术圈（ID：kube100）

无状态应用在 Kubernetes 中的使用非常方便，但是对于一些有状态应用部署还是相对较麻烦，虽然也有单独的 StatefulSets 资源对象来处理有状态应用，但是毕竟不具有通用性，有状态应用的编排和具体的应用息息相关，比如 MongoDB、ElasticSearch、Redis、Zookeeper 等应用。我们这里不再对 StatefulSets 的具体使用展开介绍了，将通过部署一个可扩展的 MongoDB 集群为例进行说明。在 Kubernetes 上编排 MongoDB 集群-鸿蒙开发者社区

首先我们运行一个 DaemonSet 的控制器来管理节点，禁用巨页，因为 MongoDB 是建议关闭掉 Transparent Hugepage 的，否则可能导致性能下降，内存锁，甚至系统重启等问题，当然最好的还是只调整 MongoDB 的 Pod 所在的节点：

# hostvm-ds.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: hostvm-configurer
  labels:
    app: startup-script
spec:
  selector:
    matchLabels:
      app: startup-script
  template:
    metadata:
      labels:
        app: startup-script
    spec:
      hostPID: true
      containers:
      - name: hostvm-configurer
        image: cnych/startup-script:v1
        securityContext:
          privileged: true
        env:
        - name: STARTUP_SCRIPT
          value: |
            #! /bin/bash
            set -o errexit
            set -o pipefail
            set -o nounset
            
            # Disable hugepages
            echo 'never' > /sys/kernel/mm/transparent_hugepage/enabled
            echo 'never' > /sys/kernel/mm/transparent_hugepage/defrag1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.

然后配置 ServiceAccount、Headless SVC 和 StatefulSet，资源清单文件如下所示：

# mongo.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: mongo
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: mongo
  namespace: mongo
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: mongo
subjects:
  - kind: ServiceAccount
    name: mongo
    namespace: mongo
roleRef:
  kind: ClusterRole
  name: cluster-admin
  apiGroup: rbac.authorization.k8s.io
---
apiVersion: v1
kind: Service
metadata:
 name: mongo
 namespace: mongo
 labels:
   name: mongo
spec:
 ports:
 - port: 27017
   targetPort: 27017
 clusterIP: None
 selector:
   role: mongo
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mongo
  namespace: mongo
spec:
  serviceName: mongo
  replicas: 3
  selector:
    matchLabels:
      role: mongo
      environment: staging
  template:
    metadata:
      labels:
        role: mongo
        environment: staging
        replicaset: MainRepSet
    spec:
      affinity:
        podAntiAffinity:  # 添加 Pod 反亲和性，将副本打散在不同的节点
          preferredDuringSchedulingIgnoredDuringExecution:  # 软策略
          - weight: 100
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: replicaset
                  operator: In
                  values:
                  - MainRepSet
              topologyKey: kubernetes.io/hostname
      terminationGracePeriodSeconds: 10
      serviceAccountName: mongo
      containers:
        - name: mongo
          image: mongo:4.0
          command:
            - mongod
            - "--wiredTigerCacheSizeGB"
            - "0.25"
            - "--bind_ip"
            - "0.0.0.0"
            - "--replSet"
            - MainRepSet
            - "--smallfiles"
            - "--noprealloc"
          ports:
            - containerPort: 27017
          volumeMounts:
            - name: mongo-data
              mountPath: /data/db
          resources:
            requests:
              cpu: 1
              memory: 2Gi
        - name: mongo-sidecar
          image: cvallance/mongo-k8s-sidecar
          env:
            - name: MONGO_SIDECAR_POD_LABELS
              value: "role=mongo,environment=staging"
            - name: KUBE_NAMESPACE
              value: "mongo"
            - name: KUBERNETES_MONGO_SERVICE_NAME
              value: "mongo"
  volumeClaimTemplates:
  - metadata:
      name: mongo-data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: rook-ceph-block  # 提供一个可用的 Storageclass
      resources:
        requests:
          storage: 10Gi1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.

这里我们给 Mongo 的 Pod 添加了一个 sidecar 容器，主要用于副本集的配置，该 sidecar 会每5s检查一次新成员。通过几个环境变量配置指定了 Pod 的标签、命名空间和 Service。

为了保证应用的稳定性，我们通过 podAntiAffinity 指定了 Pod 的反亲和性，这样可以保证不会有两个副本出现在同一个节点上。

此外需要提供一个可用的 StorageClass，这样可以保证不同的副本数据持久化到不同的 PV。

直接运行上面的两个资源清单文件即可：

$ kubectl apply -f hostvm-ds.yaml
$ kubectl apply -f mongo.yaml1.
2.

部署完成后可以通过如下命令检查应用运行状态：

$ kubectl -n mongo get all
kubectl -n mongo get all
NAME          READY   STATUS              RESTARTS   AGE
pod/mongo-0   2/2     Running             0          28m
pod/mongo-1   2/2     Running             0          23m
pod/mongo-2   2/2     Running             0          16m

NAME            TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)     AGE
service/mongo   ClusterIP   None         <none>        27017/TCP   51m

NAME                     READY   AGE
statefulset.apps/mongo   3/3     28m1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.

由于我们这里的 Service 是无头服务，没有 ClusterIP，也没有 ExternalIP，这个 Service 会直接解析到 Pod 的 IP 列表，当应用完全部署到 Kubernetes 集群上后，我们就可以按照不同的节点来进行访问了：

Node-0: mongo-0.mongo.mongo.svc.cluster.local:27017
Node-1: mongo-1.mongo.mongo.svc.cluster.local:27017
Node-2: mongo-2.mongo.mongo.svc.cluster.local:270171.
2.
3.

当然如果想从集群外部访问 mongo，可以为这些 Pod 部署一些内部的负载均衡器，或者使用 nginx-ingress、traefik 这些 Ingress 控制器来创建 Ingress 暴露出去。

我们集群中部署了 Traefik v2.2 版本，该版本是支持 TCP 服务的，我们可以通过创建一个如下所示的 IngressRoute 对象来暴露 mongo 服务：

# ingressroute-tcp.yaml
apiVersion: traefik.containo.us/v1alpha1
kind: IngressRouteTCP
metadata:
  name: mongo
  namespapce: mongo
spec:
  entryPoints:
  - mongo  # 需要通过静态方式开启 mongo 的入口点
  routes:
  - match: HostSNI(`*`)
    services:
    - name: mongo
      port: 270171.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.

由于 Traefik 暴露 TCP 服务需要 SNI 的支持，我们这里没有指定特定的域名，所以需要通过一个专门的入口点 mongo 来暴露，需要在 Traefik 中声明并开启这个入口点，类似于下面的这样静态配置：

......
- name: mongo
  containerPort: 27017
  hostPort: 27017
args:
- --entryPoints.mongo.address=:27017
......1.
2.
3.
4.
5.
6.
7.

直接运行上面的 IngressRouteTCP 对象即可：

$ kubectl apply -f ingressroute-tcp.yaml -n mongo1.

需要注意的是，应用程序至少要知道一个当前正在运行的 mongo 节点，这样才可以发现所有其他节点。

我这里本地是 Mac 系统，使用的是 Robo 3T 作为 mongo 客户端，连接到其中一个节点并运行 rs.status() 后，我们可以查看到副本集的详细信息，并检查其他两个 Pod 是否被配置并自动连接到副本集上。在 Kubernetes 上编排 MongoDB 集群-鸿蒙开发者社区

rs.status() 显示副本集名称和成员数量

在成员列表中也可以看到每个成员的 FQDN 名称和状态，不过需要注意的是 FQDN 只能在 Kubernetes 集群内部访问：在 Kubernetes 上编排 MongoDB 集群-鸿蒙开发者社区

FQDN 名称和状态

现在我们可以对 Mongo 进行扩容，以检查新的 Pod 是否被添加到副本集中去：

$ kubectl -n mongo scale statefulsets mongo --replicas=4
statefulset.apps/mongo scaled
$ kubectl -n mongo get pods -o wide
NAME      READY   STATUS    RESTARTS   AGE     IP             NODE         NOMINATED NODE   READINESS GATES
mongo-0   2/2     Running   0          32m     10.244.8.29    ydzs-node6   <none>           <none>
mongo-1   2/2     Running   0          27m     10.244.7.175   ydzs-node5   <none>           <none>
mongo-2   2/2     Running   0          20m     10.244.2.175   ydzs-node2   <none>           <none>
mongo-3   2/2     Running   0          4m29s   10.244.3.95    ydzs-node3   <none>           <none>1.
2.
3.
4.
5.
6.
7.
8.

由于上面我们配置了 Pod 的反亲和性，但是是软策略，所以4个 Pod 会经量分散到不同的节点上。扩容后同样新的 Pod 也会自动提供一个持久券：

$ kubectl -n mongo get pvc
NAME                 STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS      AGE
mongo-data-mongo-0   Bound    pvc-ac306842-f6a9-413c-bf92-576dd6a3b092   10Gi       RWO            rook-ceph-block   56m
mongo-data-mongo-1   Bound    pvc-d319e5d2-ac99-4a2b-898c-feb4bdf0f256   10Gi       RWO            rook-ceph-block   27m
mongo-data-mongo-2   Bound    pvc-fc8ded1d-0649-4b64-963e-0b9e2fc1f27d   10Gi       RWO            rook-ceph-block   21m
mongo-data-mongo-3   Bound    pvc-762b4b91-432e-4409-8d8f-e3e809d6a159   10Gi       RWO            rook-ceph-block   4m51s1.
2.
3.
4.
5.
6.

现在我们再去Robo 3T 客户端重新执行 rs.status() 检查新的 Pod 是否被添加到副本集中了：在 Kubernetes 上编排 MongoDB 集群-鸿蒙开发者社区

已经变成4个成员了

新增的 Pod 与之前的成员都采用相同的 FQDN 方案，并同步到同一个 Primary 节点去。在 Kubernetes 上编排 MongoDB 集群-鸿蒙开发者社区

到这里我们就成功地将 MongoDB 部署到了 Kubernetes 集群，而且还是可伸缩的。后续我们还可以考虑针对应用部署 VPA，或者增加一些网络策略或 Istio 来控制应用，当然这种方式整体来说是可行的，但是可维护性还不是非常高，如果可以，我们应该去根据自己的业务需求开发对应的 Operator，或者使用第三方高质量的 Operator 来编排 MongoDB。

分类

云原生

标签

Kubernetes

MongoDB

已于2022-5-9 14:26:58修改

51CTO

51CTO博客

51CTO学堂

在 Kubernetes 上编排 MongoDB 集群

订阅鸿蒙技术特刊，精选内容抢先看