Kubernetes 部署 Nebula 图数据库集群

Kubernetes 是什么

Kubernetes 是一个开源的，用于管理云平台中多个主机上的容器化的应用，Kubernetes 的目标是让部署容器化的应用简单并且高效，Kubernetes 提供了应用部署，规划，更新，维护的一种机制。
Kubernetes 在设计结构上定义了一系列的构建模块，其目的是为了提供一个可以部署、维护和扩展应用程序的机制，组成 Kubernetes 的组件设计概念为松耦合和可扩展的，这样可以使之满足多种不同的工作负载。可扩展性在很大程度上由 Kubernetes
API 提供，此 API 主要被作为扩展的内部组件以及 Kubernetes 上运行的容器来使用。

Kubernetes 主要由以下几个核心组件组成：

  • etcd? 保存了整个集群的状态
  • apiserver?提供了资源操作的唯一入口，并提供认证、授权、访问控制、API注册和发现等机制
  • controller manager?负责维护集群的状态，比如故障检测、自动扩展、滚动更新等
  • scheduler?负责资源的调度，按照预定的调度策略将Pod调度到相应的机器上
  • kubelet?负责维护容器的生命周期，同时也负责 Volume和网络的管理
  • Container runtime?负责镜像管理以及 Pod 和容器的真正运行（CRI）
  • kube-proxy?负责为 Service 提供 cluster 内部的服务发现和负载均衡

除了核心组件，还有一些推荐的 Add-ons：

  • kube-dns?负责为整个集群提供 DNS 服务
  • Ingress Controller?为服务提供外网入口
  • Heapster?提供资源监控
  • Dashboard?提供 GUI
  • Federation?提供跨可用区的集群
  • Fluentd-elasticsearch?提供集群日志采集、存储与查询

Kubernetes 和数据库

数据库容器化是最近的一大热点，那么 Kubernetes 能为数据库带来什么好处呢？

  • 故障恢复: Kubernetes 提供故障恢复的功能，数据库应用如果宕掉，Kubernetes 可以将其自动重启，或者将数据库实例迁移到集群中其他节点上
  • 存储管理: Kubernetes 提供了丰富的存储接入方案，数据库应用能透明地使用不同类型的存储系统
  • 负载均衡: Kubernetes Service 提供负载均衡功能，能将外部访问平摊给不同的数据库实例副本上
  • 水平拓展: Kubernetes 可以根据当前数据库集群的资源利用率情况，缩放副本数目，从而提升资源的利用率

目前很多数据库，如：MySQL，MongoDB 和 TiDB 在 Kubernetes 集群中都能运行很良好。

Nebula Graph在Kubernetes中的实践

Nebula Graph 是一个分布式的开源图数据库，主要组件有：Query Engine 的 graphd，数据存储的 storaged，和元数据的 meted。在 Kubernetes 实践过程中，它主要给图数据库 Nebula Graph 带来了以下的好处：

  • Kubernetes 能分摊 nebula graphd，metad 和 storaged 不副本之间的负载。graphd，metad 和 storaged 可以通过 Kubernetes 的域名服务自动发现彼此。
  • 通过 storageclass，pvc 和 pv 可以屏蔽底层存储细节，无论使用本地卷还是云盘，Kubernetes 均可以屏蔽这些细节。
  • 通过 Kubernetes 可以在几秒内成功部署一套 Nebula 集群，Kubernetes 也可以无感知地实现 Nebula 集群的升级。
  • Nebula 集群通过 Kubernetes 可以做到自我恢复，单体副本 crash，Kubernetes 可以重新将其拉起，无需运维人员介入。
  • Kubernetes 可以根据当前 Nebula 集群的资源利用率情况水平伸缩 Nebula 集群，从而提供集群的性能。

下面来讲解下具体的实践内容。

集群部署

硬件和软件要求

这里主要罗列下本文部署涉及到的机器、操作系统参数

  • 操作系统使用的 CentOS-7.6.1810 x86_64
  • 虚拟机配置
    • 4 CPU
    • 8G 内存
    • 50G 系统盘
    • 50G 数据盘A
    • 50G 数据盘B
  • Kubernetes 集群版本 v1.16
  • Nebula 版本为 v1.0.0-rc3
  • 使用本地 PV 作为数据存储

kubernetes 集群规划

以下为集群清单

服务器 IP nebula 实例 role
192.168.0.1 k8s-master
192.168.0.2 graphd, metad-0, storaged-0 k8s-slave
192.168.0.3 graphd, metad-1, storaged-1 k8s-slave
192.168.0.4 graphd, metad-2, storaged-2 k8s-slave

Kubernetes 待部署组件

  • 安装 Helm
  • 准备本地磁盘，并安装本地卷插件
  • 安装 nebula 集群
  • 安装 ingress-controller

安装 Helm

Helm 是 Kubernetes 集群上的包管理工具，类似 CentOS 上的 yum，Ubuntu 上的 apt-get。使用 Helm 可以极大地降低使用 Kubernetes 部署应用的门槛。由于本篇文章不做 Helm 详细介绍，有兴趣的小伙伴可自行阅读《Helm 入门指南》

下载安装Helm

使用下面命令在终端执行即可安装 Helm

[[email protected] ~]# wget https://get.helm.sh/helm-v3.0.1-linux-amd64.tar.gz
[[email protected] ~]# tar -zxvf helm/helm-v3.0.1-linux-amd64.tgz
[[email protected] ~]# mv linux-amd64/helm /usr/bin/helm
[[email protected] ~]# chmod +x /usr/bin/helm

查看 Helm 版本

执行 helm version?命令即可查看对应的 Helm 版本，以文本为例，以下为输出结果：

version.BuildInfo{
    Version:"v3.0.1",
    GitCommit:"7c22ef9ce89e0ebeb7125ba2ebf7d421f3e82ffa",
    GitTreeState:"clean",
    GoVersion:"go1.13.4"
}

设置本地磁盘

在每台机器上做如下配置

创建 mount 目录

[[email protected] ~]# sudo mkdir -p /mnt/disks

格式化数据盘

[[email protected] ~]# sudo mkfs.ext4 /dev/diskA
[[email protected] ~]# sudo mkfs.ext4 /dev/diskB

挂载数据盘

[[email protected] ~]# DISKA_UUID=$(blkid -s UUID -o value /dev/diskA)
[[email protected] ~]# DISKB_UUID=$(blkid -s UUID -o value /dev/diskB)
[[email protected] ~]# sudo mkdir /mnt/disks/$DISKA_UUID
[[email protected] ~]# sudo mkdir /mnt/disks/$DISKB_UUID
[[email protected] ~]# sudo mount -t ext4 /dev/diskA /mnt/disks/$DISKA_UUID
[[email protected] ~]# sudo mount -t ext4 /dev/diskB /mnt/disks/$DISKB_UUID

[[email protected] ~]# echo UUID=`sudo blkid -s UUID -o value /dev/diskA` /mnt/disks/$DISKA_UUID ext4 defaults 0 2 | sudo tee -a /etc/fstab
[[email protected] ~]# echo UUID=`sudo blkid -s UUID -o value /dev/diskB` /mnt/disks/$DISKB_UUID ext4 defaults 0 2 | sudo tee -a /etc/fstab

部署本地卷插件

[[email protected] ~]# curl https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner/archive/v2.3.3.zip
[[email protected] ~]# unzip v2.3.3.zip

修改 v2.3.3/helm/provisioner/values.yaml

#
# Common options.
#
common:
  #
  # Defines whether to generate service account and role bindings.
  #
  rbac: true
  #
  # Defines the namespace where provisioner runs
  #
  namespace: default
  #
  # Defines whether to create provisioner namespace
  #
  createNamespace: false
  #
  # Beta PV.NodeAffinity field is used by default. If running against pre-1.10
  # k8s version, the `useAlphaAPI` flag must be enabled in the configMap.
  #
  useAlphaAPI: false
  #
  # Indicates if PVs should be dependents of the owner Node.
  #
  setPVOwnerRef: false
  #
  # Provisioner clean volumes in process by default. If set to true, provisioner
  # will use Jobs to clean.
  #
  useJobForCleaning: false
  #
  # Provisioner name contains Node.UID by default. If set to true, the provisioner
  # name will only use Node.Name.
  #
  useNodeNameOnly: false
  #
  # Resync period in reflectors will be random between minResyncPeriod and
  # 2*minResyncPeriod. Default: 5m0s.
  #
  #minResyncPeriod: 5m0s
  #
  # Defines the name of configmap used by Provisioner
  #
  configMapName: "local-provisioner-config"
  #
  # Enables or disables Pod Security Policy creation and binding
  #
  podSecurityPolicy: false
#
# Configure storage classes.
#
classes:
- name: fast-disks # Defines name of storage classe.
  # Path on the host where local volumes of this storage class are mounted
  # under.
  hostDir: /mnt/fast-disks
  # Optionally specify mount path of local volumes. By default, we use same
  # path as hostDir in container.
  # mountDir: /mnt/fast-disks
  # The volume mode of created PersistentVolume object. Default to Filesystem
  # if not specified.
  volumeMode: Filesystem
  # Filesystem type to mount.
  # It applies only when the source path is a block device,
  # and desire volume mode is Filesystem.
  # Must be a filesystem type supported by the host operating system.
  fsType: ext4
  blockCleanerCommand:
  #  Do a quick reset of the block device during its cleanup.
  #  - "/scripts/quick_reset.sh"
  #  or use dd to zero out block dev in two iterations by uncommenting these lines
  #  - "/scripts/dd_zero.sh"
  #  - "2"
  # or run shred utility for 2 iteration.s
     - "/scripts/shred.sh"
     - "2"
  # or blkdiscard utility by uncommenting the line below.
  #  - "/scripts/blkdiscard.sh"
  # Uncomment to create storage class object with default configuration.
  # storageClass: true
  # Uncomment to create storage class object and configure it.
  # storageClass:
    # reclaimPolicy: Delete # Available reclaim policies: Delete/Retain, defaults: Delete.
    # isDefaultClass: true # set as default class

#
# Configure DaemonSet for provisioner.
#
daemonset:
  #
  # Defines the name of a Provisioner
  #
  name: "local-volume-provisioner"
  #
  # Defines Provisioner's image name including container registry.
  #
  image: quay.io/external_storage/local-volume-provisioner:v2.3.3
  #
  # Defines Image download policy, see kubernetes documentation for available values.
  #
  #imagePullPolicy: Always
  #
  # Defines a name of the service account which Provisioner will use to communicate with API server.
  #
  serviceAccount: local-storage-admin
  #
  # Defines a name of the Pod Priority Class to use with the Provisioner DaemonSet
  #
  # Note that if you want to make it critical, specify "system-cluster-critical"
  # or "system-node-critical" and deploy in kube-system namespace.
  # Ref: https://k8s.io/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical
  #
  #priorityClassName: system-node-critical
  # If configured, nodeSelector will add a nodeSelector field to the DaemonSet PodSpec.
  #
  # NodeSelector constraint for local-volume-provisioner scheduling to nodes.
  # Ref: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#nodeselector
  nodeSelector: {}
  #
  # If configured KubeConfigEnv will (optionally) specify the location of kubeconfig file on the node.
  #  kubeConfigEnv: KUBECONFIG
  #
  # List of node labels to be copied to the PVs created by the provisioner in a format:
  #
  #  nodeLabels:
  #    - failure-domain.beta.kubernetes.io/zone
  #    - failure-domain.beta.kubernetes.io/region
  #
  # If configured, tolerations will add a toleration field to the DaemonSet PodSpec.
  #
  # Node tolerations for local-volume-provisioner scheduling to nodes with taints.
  # Ref: https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/
  tolerations: []
  #
  # If configured, resources will set the requests/limits field to the Daemonset PodSpec.
  # Ref: https://kubernetes.io/docs/concepts/configuration/manage-compute-resources-container/
  resources: {}
#
# Configure Prometheus monitoring
#
prometheus:
  operator:
    ## Are you using Prometheus Operator?
    enabled: false

    serviceMonitor:
      ## Interval at which Prometheus scrapes the provisioner
      interval: 10s

      # Namespace Prometheus is installed in
      namespace: monitoring

      ## Defaults to whats used if you follow CoreOS [Prometheus Install Instructions](https://github.com/coreos/prometheus-operator/tree/master/helm#tldr)
      ## [Prometheus Selector Label](https://github.com/coreos/prometheus-operator/blob/master/helm/prometheus/templates/prometheus.yaml#L65)
      ## [Kube Prometheus Selector Label](https://github.com/coreos/prometheus-operator/blob/master/helm/kube-prometheus/values.yaml#L298)
      selector:
        prometheus: kube-prometheus

将hostDir: /mnt/fast-disks 改成hostDir: /mnt/disks
将# storageClass: true 改成 storageClass: true
然后执行：

#安装
[[email protected] ~]# helm install local-static-provisioner v2.3.3/helm/provisioner
#查看local-static-provisioner部署情况
[[email protected] ~]# helm list

部署 nebula 集群

下载 nebula helm-chart 包

# 下载nebula
[[email protected] ~]# wget https://github.com/vesoft-inc/nebula/archive/master.zip
# 解压
[[email protected] ~]# unzip master.zip

设置 Kubernetes slave 节点

下面是 Kubernetes 节点列表，我们需要设置 slave 节点的调度标签。可以将 192.168.0.2，192.168.0.3，192.168.0.4?打上 nebula: "yes" 的标签。

服务器 IP kubernetes roles nodeName
192.168.0.1 master 192.168.0.1
192.168.0.2 worker 192.168.0.2
192.168.0.3 worker 192.168.0.3
192.168.0.4 worker 192.168.0.4

具体操作如下：

[[email protected] ~]# kubectl  label node 192.168.0.2 nebula="yes" --overwrite
[[email protected] ~]# kubectl  label node 192.168.0.3 nebula="yes" --overwrite
[[email protected] ~]# kubectl  label node 192.168.0.4 nebula="yes" --overwrite

调整 nebula helm chart 默认的 values 值

nebula helm-chart 包目录如下:

master/kubernetes/
└── helm
    ├── Chart.yaml
    ├── templates
    │?? ├── configmap.yaml
    │?? ├── deployment.yaml
    │?? ├── _helpers.tpl
    │?? ├── ingress-configmap.yaml\
    │?? ├── NOTES.txt
    │?? ├── pdb.yaml
    │?? ├── service.yaml
    │?? └── statefulset.yaml
    └── values.yaml

2 directories, 10 files

我们需要调整 master/kubernetes/values.yaml? 里面的 MetadHosts 的值，将这个 IP List 替换本环境的 3 个 k8s worker 的 ip。

MetadHosts:
  - 192.168.0.2:44500
  - 192.168.0.3:44500
  - 192.168.0.4:44500

通过 helm 安装 nebula

# 安装
[[email protected] ~]# helm install nebula master/kubernetes/helm
# 查看
[[email protected] ~]# helm status nebula
# 查看k8s集群上nebula部署情况
[[email protected] ~]# kubectl get pod  | grep nebula
nebula-graphd-579d89c958-g2j2c                   1/1     Running            0          1m
nebula-graphd-579d89c958-p7829                   1/1     Running            0          1m
nebula-graphd-579d89c958-q74zx                   1/1     Running            0          1m
nebula-metad-0                                   1/1     Running            0          1m
nebula-metad-1                                   1/1     Running            0          1m
nebula-metad-2                                   1/1     Running            0          1m
nebula-storaged-0                                1/1     Running            0          1m
nebula-storaged-1                                1/1     Running            0          1m
nebula-storaged-2                                1/1     Running            0          1m

部署 Ingress-controller

Ingress-controller 是 Kubernetes 的一个 Add-Ons。Kubernetes 通过 ingress-controller 将 Kubernetes 内部署的服务暴露给外部用户访问。Ingress-controller 还提供负载均衡的功能，可以将外部访问流量平摊给 k8s 中应用的不同的副本。

选择一个节点部署 Ingress-controller

[[email protected] ~]# kubectl get node
NAME              STATUS     ROLES    AGE   VERSION
192.168.0.1       Ready      master   82d   v1.16.1
192.168.0.2       Ready      <none>   82d   v1.16.1
192.168.0.3       Ready      <none>   82d   v1.16.1
192.168.0.4       Ready      <none>   82d   v1.16.1
[[email protected] ~]# kubectl label node 192.168.0.4 ingress=yes

编写 ingress-nginx.yaml 部署文件

apiVersion: v1
kind: Namespace
metadata:
  name: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
---
kind: ConfigMap
apiVersion: v1
metadata:
  name: nginx-configuration
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
---
kind: ConfigMap
apiVersion: v1
metadata:
  name: tcp-services
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
---
kind: ConfigMap
apiVersion: v1
metadata:
  name: udp-services
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: nginx-ingress-serviceaccount
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:
  name: nginx-ingress-clusterrole
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
rules:
  - apiGroups:
      - ""
    resources:
      - configmaps
      - endpoints
      - nodes
      - pods
      - secrets
    verbs:
      - list
      - watch
  - apiGroups:
      - ""
    resources:
      - nodes
    verbs:
      - get
  - apiGroups:
      - ""
    resources:
      - services
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - "extensions"
      - "networking.k8s.io"
    resources:
      - ingresses
    verbs:
      - get
      - list
      - watch
  - apiGroups:
      - ""
    resources:
      - events
    verbs:
      - create
      - patch
  - apiGroups:
      - "extensions"
      - "networking.k8s.io"
    resources:
      - ingresses/status
    verbs:
      - update
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: Role
metadata:
  name: nginx-ingress-role
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
rules:
  - apiGroups:
      - ""
    resources:
      - configmaps
      - pods
      - secrets
      - namespaces
    verbs:
      - get
  - apiGroups:
      - ""
    resources:
      - configmaps
    resourceNames:
      # Defaults to "<election-id>-<ingress-class>"
      # Here: "<ingress-controller-leader>-<nginx>"
      # This has to be adapted if you change either parameter
      # when launching the nginx-ingress-controller.
      - "ingress-controller-leader-nginx"
    verbs:
      - get
      - update
  - apiGroups:
      - ""
    resources:
      - configmaps
    verbs:
      - create
  - apiGroups:
      - ""
    resources:
      - endpoints
    verbs:
      - get
---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: RoleBinding
metadata:
  name: nginx-ingress-role-nisa-binding
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: nginx-ingress-role
subjects:
  - kind: ServiceAccount
    name: nginx-ingress-serviceaccount
    namespace: ingress-nginx

---
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:
  name: nginx-ingress-clusterrole-nisa-binding
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: nginx-ingress-clusterrole
subjects:
  - kind: ServiceAccount
    name: nginx-ingress-serviceaccount
    namespace: ingress-nginx

---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: nginx-ingress-controller
  namespace: ingress-nginx
  labels:
    app.kubernetes.io/name: ingress-nginx
    app.kubernetes.io/part-of: ingress-nginx
spec:
  selector:
    matchLabels:
      app.kubernetes.io/name: ingress-nginx
      app.kubernetes.io/part-of: ingress-nginx
  template:
    metadata:
      labels:
        app.kubernetes.io/name: ingress-nginx
        app.kubernetes.io/part-of: ingress-nginx
      annotations:
        prometheus.io/port: "10254"
        prometheus.io/scrape: "true"
    spec:
      hostNetwork: true
      tolerations:
        - key: "node-role.kubernetes.io/master"
          operator: "Exists"
          effect: "NoSchedule"
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            - labelSelector:
                matchExpressions:
                  - key: app.kubernetes.io/name
                    operator: In
                    values:
                      - ingress-nginx
              topologyKey: "ingress-nginx.kubernetes.io/master"
      nodeSelector:
        ingress: "yes"
      serviceAccountName: nginx-ingress-serviceaccount
      containers:
        - name: nginx-ingress-controller
          image: quay.io/kubernetes-ingress-controller/nginx-ingress-controller-amd64:0.26.1
          args:
            - /nginx-ingress-controller
            - --configmap=$(POD_NAMESPACE)/nginx-configuration
            - --tcp-services-configmap=default/graphd-services
            - --udp-services-configmap=$(POD_NAMESPACE)/udp-services
            - --publish-service=$(POD_NAMESPACE)/ingress-nginx
            - --annotations-prefix=nginx.ingress.kubernetes.io
            - --http-port=8000
          securityContext:
            allowPrivilegeEscalation: true
            capabilities:
              drop:
                - ALL
              add:
                - NET_BIND_SERVICE
            # www-data -> 33
            runAsUser: 33
          env:
            - name: POD_NAME
              valueFrom:
                fieldRef:
                  fieldPath: metadata.name
            - name: POD_NAMESPACE
              valueFrom:
                fieldRef:
                  fieldPath: metadata.namespace
          ports:
            - name: http
              containerPort: 80
            - name: https
              containerPort: 443
          livenessProbe:
            failureThreshold: 3
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            initialDelaySeconds: 10
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 10
          readinessProbe:
            failureThreshold: 3
            httpGet:
              path: /healthz
              port: 10254
              scheme: HTTP
            periodSeconds: 10
            successThreshold: 1
            timeoutSeconds: 10

部署 ingress-nginx

# 部署
[[email protected] ~]# kubectl create -f ingress-nginx.yaml
# 查看部署情况
[[email protected] ~]# kubectl get pod -n ingress-nginx
NAME                             READY   STATUS    RESTARTS   AGE
nginx-ingress-controller-mmms7   1/1     Running   2          1m

访问 nebula 集群

查看 ingress-nginx 所在的节点：

[[email protected] ~]# kubectl get node -l ingress=yes -owide
NAME            STATUS   ROLES    AGE   VERSION   INTERNAL-IP    EXTERNAL-IP   OS-IMAGE                KERNEL-VERSION          CONTAINER-RUNTIME
192.168.0.4     Ready    <none>   1d   v1.16.1    192.168.0.4    <none>        CentOS Linux 7 (Core)   7.6.1810.el7.x86_64     docker://19.3.3

访问 nebula 集群:

[[email protected] ~]# docker run --rm -ti --net=host vesoft/nebula-console:nightly --addr=192.168.0.4 --port=3699

FAQ

如何搭建一套 Kubernetes 集群？

搭建高可用的 Kubernetes 可以参考社区文档：https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/

你也可以通过 minikube 搭建本地的 Kubernetes 集群，参考文档：https://kubernetes.io/docs/setup/learning-environment/minikube/

如何调整 nebula 集群的部署参数?

在使用 helm install 时，使用 --set 可以设置部署参数，从而覆盖掉 helm chart 中 values.yaml 中的变量。参考文档：https://helm.sh/docs/intro/using_helm/

如何查看 nebula 集群状况？

使用kubectl get pod | grep nebula命令，或者直接在 Kubernetes dashboard 上查看 nebula 集群的运行状况。

如何使用其他类型的存储？

参考文档：https://kubernetes.io/zh/docs/concepts/storage/storage-classes/

参考资料

附录

原文地址：https://www.cnblogs.com/nebulagraph/p/12368136.html

时间： 2024-10-10 20:37:36

Kubernetes 部署 Nebula 图数据库集群的相关文章

构建读写分离的数据库集群

4.1实战案例——构建读写分离的数据库集群 使用Mycat作为数据库中间件服务构建读写分离的数据库集群 使用一台虚拟机部署Mycat数据库中间件服务,将用户提交的读写操作识别分发给相应的数据库 节点.这样将用户的访问操作.数据库的读与写操作分给3台主机,只有数据库集群的主节点接 收增.删.改SQL语句,从节点接收查询语句,分担了主节点的查询压力 基础准备 使用CentOS 7.2系统,创建3台虚拟机进行实验. 其中2台虚拟机db1和db2部署MariaDB数据库服务,搭建主从数据库集群:一台作为

【Data Cluster】真机环境下MySQL数据库集群搭建

阅读目录 MySQL Cluster简介 mysql-cluster构造 虚拟机安装centos6.6 mysql-cluster下载 centos6.6搭建环境配置 mysql-cluster安装包导入cent中 集群配置 运行mysql-cluster 常见问题 测试 真机环境下MySQL-Cluster搭建文档  摘要:本年伊始阶段,由于实验室对不同数据库性能测试需求,才出现MySQL集群搭建.购置主机,交换机,双绞线等一系列准备工作就绪,也就开始集群搭建.起初笔者对此不甚了解,查阅很多资

浅谈数据库集群（一）

现在,随着上网人数的激增,一些大型的网站开始使用数据库集群来提高数据库的可靠性和数据库的性能.那么在介绍数据库集群之前首先需要弄清楚几个问题. 1.为什么要用数据库集群 (1)通过使用数据库集群可以使读写分离,提高数据库的系统性能. 大家都知道,mysql是支持分布式的.MySQL Proxy最强大的一项功能是实现"读写分离(Read/Write Splitting)".基本的原理是让主数据库处理事务性查询,而从数据库处 理SELECT查询.数据库复制被用来把事务性查询导致的变更同步到

架构设计之「数据库集群方案」

在之前的文章中,我们知道数据库服务可能已经成为了很多系统的性能关键点,甚至是瓶颈了.也给大家介绍了数据库服务器从主备架构.到主从架构.再到主主架构的基础方案.但如果单台机器已经不能满足完整业务数据存储的时候,我们就需要考虑采用多机甚至多中心的部署方案了. 今天我们就再来聊一聊,在多机环境下,数据库集群的架构方案. 同样,这里先不看细节,不管底层数据源是什么数据库,我们先谈架构方案.因为无论底层是 Mysql 还是 Redis.MongoDB,我们在架构设计上都是相通的. 针对多机的架构,常见有如

浅谈高性能数据库集群——读写分离

本文主要介绍高性能数据库集群读写分离相关理论,基本架构,涉及的复杂度问题以及常见解决方案. 1 读写分离概述 基本架构图: 2 适用场景 读写分离不是银弹,并不是一有性能问题就上读写分离,而是应该先优化,例如优化慢查询,调整不合理的业务逻辑,引入缓存查询等只有确定系统没有优化空间后才考虑读写分离集群 3 引入的系统复杂度问题 问题一 主从复制延迟 问题二 分配机制 如何将读写操作区分开来,然后访问不同的数据库服务器? 解决方案1 客户端程序代码封装实现 基本架构图 业界开源实现 Sharding

PhxSQL兼容MySQL的关系型数据库集群

PhxSQL是一个兼容MySQL.服务高可用.数据强一致的关系型数据库集群.PhxSQL以单Master多Slave方式部署,在集群内超过一半机器存活的情况下,可自身实现自动Master切换,且保证数据一致性. PhxSQL 架构: PhxSQL基于Percona 5.6开发.Percona是MySQL的一个分支,功能和实现与MySQL基本一致(基础教程qkxue.net).因此本文后续直接把MySQL作为讨论对象. 总览: PhxSQL具有服务高可用.数据强一致.高性能.运维简单.和MySQL

数据库集群技术漫谈

转自:http://www.51testing.com/html/69/n-867469-2.html 简介 当今世界是一个信息化的世界,我们的生活中无论是生活.工作.学习都离不开信息系统的支撑.而信息系统的背后用于保存和处理最终结果的地方就是数据库.因此数据库系统就变得尤为重要,这意味着如果数据库如果面临问题,则意味着整个应用系统也会面临挑战,从而带来严重的损失和后果. 如今“大数据”这个词已经变得非常流行,虽然这个概念如何落地不得而知.但可以确定的是,随着物联网.移动应用的兴起,数据量相比过

关于大型高并发网站架构以及数据库集群的一些问题

2014年6月11日,正在办理离职交接过程中,对未来的职业规划陷入了一些困境,想要专门从事管理工作,但是在任职期间所执行的管理工作仅仅属于team leader级别的,离项目经理感觉能力还有差距.对技术方面,总是有着难以克制的热情,多年的企业应用开发,锻炼了将需求转化为程序逻辑的能力.可对当下比较吃香的大型网站架构以及数据库集群技术,接触甚少.这也让我一直心有芥蒂,总想向着这个方向去探索.我想,如果想要成为一个好的架构师,这些事情如果不接触,你都不好意思跟人说你会做系统架构吧. IT给人的感觉就

简单使用Mysql-Cluster-7.5搭建数据库集群

阅读目录 前言 mysql cluster中的几个概念解释 架构图及说明 下载mysql cluster 安装mysql cluster之前 安装配置管理节点 安装配置数据和mysql节点 测试 启动和关闭 总结 |前言 当你的业务到达一定的当量,肯定需要一定数量的数据库来负载均衡你的数据库请求,我在之前的博客中已经说明了,如何实现负载均衡,但是还有一个问题就是数据同步,因为负载均衡的前提就是,各个服务器的数据库是数据同步的.在业务量不大的时候,我们会使用主从复制的方法实现服务器数据同步,一主多