在Kubernetes上扩展MongoDB，这样可以吗？

Kubernetes主要用于无状态应用程序。 但是，在1.3版本中引入了PetSets，之后它们演变为StatefulSets。 官方文档将StatefulSets描述为“StatefulSets旨在与有状态应用程序和分布式系统一起使用”。

对此最好的用例之一是对数据存储服务进行编排，例如MongoDB，ElasticSearch，Redis，ZooKeeper等。

我们可以把StatefulSets的特性归纳如下：

有序索引Pod

稳定的网络ID

有序并行的Pod管理

滚动更新

这些细节可以在这里[1]找到。

StatefulSets的一个非常明显的特征是提供稳定网络ID，与Headless Services[2]一起使用时，功能可以更加强大。

我们在Kubernetes文档中随时可以查看的信息上不会花费很多时间，让我们专注于运行和扩展MongoDB集群。

你需要一个可以运行的Kubernetes群集并启用RBAC（推荐）。 在本教程中，我将使用GKE集群，但是，AWS EKS或Microsoft的AKS或Kops管理的Kubernetes也是可行的替代方案。

我们将为MongoDB集群部署以下组件：

配置HostVM的Daemon Set

Mongo Pod的Service Account和ClusterRole Binding

为Pod提供永久性存储SSDs的Storage Class

访问Mongo容器的Headless Service

Mongo Pods Stateful Set

GCP Internal LB：从Kubernetes集群外部访问MongoDB（可选）

使用Ingress访问Pod（可选）

值得注意的是，每个MongoDB Pod都会运行一个Sidecar，以便动态配置副本集。Sidecar每5秒检查一次新成员。

Daemon Set for HostVM Configuration

kind: DaemonSet apiVersion: extensions/v1beta1 metadata: name: hostvm-configurer labels: app: startup-script spec: template: metadata: labels: app:startup-script spec: hostPID: true containers: - name: hostvm-configurer-container image: gcr.io/google-containers/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/defrag

Configuration for ServiceAccount, Storage Class, Headless SVC and StatefulSet

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:mongosubjects: - kind: ServiceAccount name: mongo namespace: mongo roleRef: kind: ClusterRole name: cluster-admin apiGroup: rbac. authorization. k8s. io --- apiVersion: storage.k8s.io/v1beta1 kind: StorageClass metadata: name: fast provisioner: kubernetes. io/gce-pd parameters: type: pd-ssd fsType: xfs allowVolumeExpansion: true --- 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/v1beta1 kind: StatefulSet metadata: name: mongo namespace: mongo spec: serviceName: mongo replicas: 3 template: metadata: labels: role: mongo environment: staging replicaset: MainRepSet spec: affinity: podAntiAffinity: 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 command: - mongo -"--wiredTigerCacheSizeGB" - "0.25" - "--bind_ip" - "0.0.0.0" - "--replSet" - MainRepSet - "--smallfiles" - "--noprealloc" ports: - containerPort: 27017 volumeMounts: - name: mongo-persistent-storage 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-persistent-storage annotations: volume.beta.kubernetes.io/storage- class:"fast" spec: accessModes: ["ReadWriteOnce" ] storageClassName : fast resources: requests: storage: 10Gi

关键点：

应该使用适当的环境变量仔细配置Mongo的Sidecar，以及为Pod提供的标签，和为deployment和service的命名空间。 有关Sidecar容器的详细信息，请点击此处[3]。

默认缓存大小的指导值是：“50％的RAM减去1GB，或256MB”。 鉴于所请求的内存量为2GB，此处的WiredTiger缓存大小已设置为256MB。

Inter-Pod Anti-Affinity确保在同一个工作节点上不会安排2个Mongo Pod，从而使其能够适应节点故障。 此外，建议将节点保留在不同的可用区中，以便集群能够抵御区域故障。
当前部署的Service Account具有管理员权限。 但是，它应该仅限于DB的命名空间。
上面提到的两个配置文件也可以在这里[4]找到。

部署MongoDB集群

kubectl apply -f configure-node.yml kubectl apply -f mongo.yml

你可以通过以下命令查看所有组件状况：

root$ kubectl -n mongo get all NAME DESIRED CURRENT AGE statefulsets/mongo 3 3 3m NAME READY STATUS RESTARTS AGE po/mongo-0 2/2 Running 0 3m po/mongo-1 2/2 Running 0 2m po/mongo-2 2/2 Running 0 1m NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S AGE svc/mongo ClusterIP None <none> 27017/TCP 3m

如你所见，该服务没有Cluster-IP，也没有External-IP，它是Headless服务。 此服务将直接解析为StatefulSets的Pod-IP。

让我们来验证一下DNS解析。 我们在集群中启动了一个交互式shell：

kubectl run my-shell --rm -i --tty --image ubuntu -- bash root@my-shell-68974bb7f7-cs4l9:/# dig mongo.mongo +search +noall +answer ; <<>>DiG9.11.3-1ubuntu1.1-Ubuntu <<>> mongo.mongo +search +noall +answer;; global options:+cmd mongo.mongo.svc.cluster.local.30 IN A 10.56.7.10 mongo.mongo.svc.cluster.local30 IN A 10.56.8.11 mongo.mongo.svc.cluster.local. 30 IN A 10.56.1.4

服务的DNS规则是<服务名称>.<服务的命名空间>，因此，在我们的例子中看到的是mongo.mongo。

IPs（10.56.6.17,10.56.7.10,10.56.8.11）是我们的Mongo StatefulSets的Pod IPs。 这可以通过在集群内部运行nslookup来测试。

root@my-shell-68974bb7f7-cs4l9:/# nslookup 10.56.6.17 17.6.56.10.in-addr.arpa name = mongo-0.mongo.mongo.svc.cluster.local. root@my-shell-68974bb7f7-cs4l9:/# nslookup 10.56.7.1010.7.56.10.in-addr.arpa name = mongo-1.mongo. mongo.svc.cluster.local. root@my-shell-68974bb7f7-cs4l9:/# nslookup 10.56.8.1111.8. 56.10.in-addr.arpa name = mongo-2.mongo.mongo.svc.cluster.local.

如果你的应用程序部署在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 : 27017

如果要从集群外部访问Mongo节点，你可以为每个Pod部署内部负载平衡或使用Ingress Controller（如NGINX或Traefik）创建一个内部Ingress。
GCP Internal LB SVC Configuration（可选）

apiVersion : v1 kind : Service metadata : annotations : cloud . google . com / load - balancer - type : Internal name : mongo - 0 namespace : mongo spec : ports : - port : 27017 targetPort : 27017 selector : statefulset . kubernetes . io / pod - name : mongo - 0 type : LoadBalancer

为mongo-1和mongo-2也部署2个此类服务。

你可以将内部负载均衡的IP提供给MongoClient URI。

root$ kubectl - n mongo get svc NAME TYPE CLUSTER - IP EXTERNAL - IP PORT ( S ) AGE mongo ClusterIP None <none> 27017 / TCP 15m mongo - 0 LoadBalancer 10.59 . 252.157 10.20 . 20.2 27017 : 30184 / TCP 9m mongo - 1 LoadBalancer 10.59 . 252.235 10.20 . 20.3 27017 : 30343 / TCP 9m mongo - 2 LoadBalancer 10.59.254.199 10.20.20.4 27017:31298/ TCP 9m

mongo-0/1/2的外部IP是新创建的TCP负载均衡器的IP。 这些是您的子网或对等网络，如果有的话。

通过Ingress访问Pod（可选）

也可以使用诸如Nginx之类的Ingress Controller来定向到Mongo StatefulSets的流量。 确保Ingress服务是内部服务，而不是通过PublicIP公开。 Ingress对象的配置看起来像这样：

... spec: rules:- host: mongo.example.com http: paths: - path:'/mongo-0' backend: hostNames: - mongo-0 serviceName: mongo # There is no extra service. This is the headless service. servicePort: '27017'

请务必注意，您的应用程序至少应该知道一个当前处于启动状态的Mongo节点，这样可以发现所有其他节点。

我在本地mac上使用Robo 3T作为mongo客户端。 连接到其中一个节点后并运行rs.status()，您可以查看副本集的详细信息，并检查是否已配置其他2个Pod并自动连接到副本集。

rs.status()查看副本集名称和成员个数

每个成员都可以看到FQDN和状态。 此FQDN只能从群集内部访问。

每个secondary成员正在同步到mongo-0，mongo-0是当前的primary。

现在我们扩展mongo Pods的Stateful Set以检查新的Mongo容器是否被添加到ReplicaSet。

 root$ kubectl - n mongo scale statefulsets mongo -- replicas = 4 statefulset "mongo" scaled root$ kubectl - n mongo get pods - o wide NAME READY STATUS RESTARTS AGE IP NODE mongo - 0 2 / 2 Running 0 25m 10.56 . 6.17 gke - k8 - demo - demo - k8 - pool - 1 - 45712bb7 - vfqs mongo - 1 2 / 2 Running 0 24m 10.56.7.10 gke - k8 - demo - demo - k8 - pool - 1 - c6901f2e - trv5 mongo - 2 2 / 2 Running 0 23m 10.56.8.11 gke - k8 - demo - demo - k8 - pool - 1 - c7622fba - qayt mongo - 3 2 / 2 Running 0 3m 10.56.1.4 gke - k8 - demo - demo - k8 - pool - 1 - 85308bb7 - 89a4

可以看出，所有四个Pod都部署到不同的GKE节点，因此我们的Pod-Anti Affinity策略工作正常。

扩展操作还将自动提供持久卷，该卷将充当新Pod的数据目录。

 root$ kubectl - n mongo get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE mongo - persistent - storage - mongo - 0 Bound pvc - 337fb7d6 - 9f8f - 11e8 - bcd6 - 42010a940024 11G RWO fast 49m mongo - persistent - storage - mongo - 1 Bound pvc - 53375e31 - 9f8f - 11e8 - bcd6 - 42010a940024 11G RWO fast 49m mongo - persistent - storage - mongo - 2 Bound pvc - 6cee0f97 - 9f8f - 11e8 - bcd6 - 42010a940024 11G RWO fast 48m mongo - persistent - storage - mongo - 3 Bound pvc - 3e89573f - 9f92 - 11e8 - bcd6 - 42010a940024 11G RWO fast 

要检查名为mongo-3的Pod是否已添加到副本集，我们将在同一节点上再次运行rs.status()并观察其差异。

对于同一个的Replicaset，成员数现在为4。

新添加的成员遵循与先前成员相同的FQDN方案，并且还与同一主节点同步。

进一步的考虑

给Mongo Pod的Node Pool打上合适的label并确保在StatefulSets和HostVM配置的DaemonSets的Spec中指定适当的Node Affinity会很有帮助。 这是因为DaemonSet将调整主机操作系统的一些参数，并且这些设置应仅限于MongoDB Pod。 没有这些设置，对其他应用程序可能会更好。

在GKE中给Node Pool打Label非常容易，可以直接从GCP控制台进行。

虽然我们在Pod的Spec中指定了CPU和内存限制，但我们也可以考虑部署VPA（Vertical Pod Autoscaler）。

可以通过实施网络策略或服务网格（如Istio）来控制从集群内部到我们的数据库的流量。

如果你已经看到这里，我相信你已经浏览了整个博文。 我试图整理很多分散的信息并将其作为一个整体呈现。 我的目标是为您提供足够的信息，以便开始使用Kubernetes上的Stateful Sets，并希望你们中的许多人觉得它很有用。 我们非常欢迎您提出反馈、意见或建议。:)

原文发布时间为：2018-12-13
本文作者： kelvinji2009 译
本文来自云栖社区合作伙伴“ 数据和云”，了解相关信息可以关注“OraNews”微信公众号