为什么抉择 Kubernetes
容器是打包和运行应用程序的好形式。在生产环境中,咱们须要治理运行应用程序的容器,并确保不会停机。如果一个容器产生故障,则须要启动另一个容器。如果零碎解决此行为,会不会更便捷?这就是 Kubernetes(后文简称K8s) 的价值所在,它为你提供了一个可弹性运行分布式系统的框架。K8s 用于治理容器化的工作负载和服务,可促成申明式配置和自动化。 同时,k8s 为你提供了主动部署和回滚、服务发现和负载平衡、存储编排、自我修复、密钥与配置管理等很多性能。即便有一些对于 k8s 复杂性的埋怨,咱们依然深信它带来的好处远大于复杂性老本。
Kubernetes 如何保护利用状态
Kubernetes 在其晚期阶段次要针对无状态应用程序(不治理本人的持久性数据的应用程序),这一个性直到 k8s 引入了 persistent volumes(长久卷)和 StatefulSet 后失去了晋升。通常,当 Kubernetes 容器死亡时,它将被具备新标识(包含新IP地址和主机名)的新容器替换。然而,StatefulSet性能可确保每个 Pod 具备本人的稳固身份(可通过DNS解析),无论它被重启了多少次。这对云溪数据库(云溪数据库)很有用,因为这意味着每次更换或重启 Pod 时,咱们不用将其视为集群中的新节点,也防止了大量数据复制。这对于反对 云溪数据库的共识协定和分布式事务十分重要。作为云原生数据库,云溪数据库能够容忍失落单个数据节点的数据失落,它能检测到集群中缺失的正本,并主动增加新正本。出于升高提早的思考,咱们举荐您应用本地磁盘作为存储,尽管近程存储容许正本在不失落数据的状况下挪动。
为什么在 Kubernetes 上应用云溪数据库
少数状况下,在 K8s 上部署、运维云溪数据库比在物理机或虚拟机上更不便。这次要因为 云溪数据库是单个可执行文件,可通过每个节点提供到数据库的通用网关。每个节点都是全对等的,惟一的区别是该节点治理的是哪局部数据。当遇到间歇性故障或进行滚动降级时, K8s 助力于数据库集群的疾速复原。只管 K8s 带来许多诸多的便当,咱们依然要衡量 k8s 带给咱们的弹性与通过物理机或虚拟机取得更高性能的利弊。即便在物理机或虚拟机上保护数据库须要更多的人工操作,但取得的最佳性能比 k8s 上要好。
云溪数据库如何运行在 Kubernetes 上
一、创立数据库集群
1.如果您没有应用网络存储而是本地存储卷时,须要创立3个 persistent volumes(长久卷)来提供给 pod 应用:
$ kubectl apply -f pv0.yaml -f pv1.yaml -f pv2.yaml
可参考以下的长久卷(pv)yaml文件:
apiVersion: v1kind: PersistentVolumemetadata: name: pv-bini-0 labels: app: binispec: capacity: storage: 10Gi volumeMode: Filesystem accessModes: - ReadWriteOnce storageClassName: local persistentVolumeReclaimPolicy: Retain local: path: /home/inspur/pv/pv0 nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: ['slave1']
2.在筹备好 Kubernetes 的环境后,您能够应用 yaml 文件去创立 StatefulSet 来创立数据库集群:
$ kubectl create -f bini-statefulset.yamlservice/bini-public createdservice/bini createdpoddisruptionbudget.policy/bini-budget createdstatefulset.apps/bini created
3.因为咱们还未初始化集群,三个 Pods 处于 running 状态:
$ kubectl get podsNAME READY STATUS RESTARTS AGEbini-0 0/1 Running 0 1mbini-1 0/1 Running 0 1mbini-2 0/1 Running 0 1m
4.查看本地长久卷申明与本地长久卷曾经胜利绑定:
$ kubectl get persistentvolumeclaimsNAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGEdatadir-bini-0 Bound pv-bini-1 1Gi RWO local 2mdatadir-bini-1 Bound pv-bini-0 1Gi RWO local 2mdatadir-bini-2 Bound pv-bini-2 1Gi RWO local 2m
5.创立集群初始化的 yaml 文件:
$ kubectl create -f cluster-init.yamljob.batch/cluster-init created
6.用于初始化的 job 将很快处于 completed 状态:
$ kubectl get job cluster-initNAME COMPLETIONS DURATION AGEcluster-init 1/1 10s 30s
数据库节点的三个 pods 也将处于 running 状态:
$ kubectl get podsNAME READY STATUS RESTARTS AGEcluster-init-bw928 0/1 Completed 0 50sbini-0 1/1 Running 0 3m23sbini-1 1/1 Running 0 3m23sbini-2 1/1 Running 0 3m23s
二、应用内置的 SQL 客户端:1.启动一个长期的交互式 pod 并启动其中的内置 SQL 客户端:
$ kubectl run bini -it \--image=bini:release2.0 \--rm \--restart=Never \-- sql \--insecure \--host=bini-public
2.运行一些 SQL 语句:
root@bini-public:26257/defaultdb> create database bank;root@bini-public:26257/defaultdb> create database bank;root@bini-public:26257/defaultdb> create table bank.accounts (name varchar(255),balance decimal);root@bini-public:26257/defaultdb> insert into bank.accounts values ('Andy',100),('Bob',200),('Chris',300);root@bini-public:26257/defaultdb> select * from bank.accounts; name | balance +-------+---------+ Andy | 100 Bob | 200 Chris | 300 (3 rows)
3.退出 SQL shell 后这个 pod 也随之删除
root@bini-public:26257/defaultdb> \q
三、通过 Admin UI 查看集群状态
办法一:为 Service 设置NodePort
应用 Service 中的 NodePort,将 Admin UI 的端口映射到本地机器的一个端口上,采纳 localhost + NodePort 的形式拜访。
办法二:应用端口转发的形式手动将 K8s 中的 Service 转发到本地机器的一个端口上
$ kubectl port-forward service/bini-public --address 0.0.0.0 8080:8080Forwarding from 0.0.0.0:8080 -> 8080
治理集群
一、减少节点
$ kubectl scale statefulset bini --replicas=4statefulset.apps/bini scaled
在配置好新的本地长久存储卷后,将看到第4个 pod 胜利退出集群:
NAME READY STATUS RESTARTS AGEcluster-init-bw928 0/1 Completed 0 1m39sbini-0 1/1 Running 0 4m12sbini-1 1/1 Running 0 4m12sbini-2 1/1 Running 0 4m12sbini-3 1/1 Running 0 30s
二、移除节点
1.启动一个长期的交互式pod,并应用bini node status命令获取数据库节点的外部ID:
$ kubectl run bini -it \--image=bini/release2.0 \--rm \--restart=Never \-- node status \--insecure \--host=bini-public id | address | build | started_at | updated_at | is_available | is_live +----+---------------------------------------------+---------+----------------------------+----------------------------+--------------+---------+ 1 | bini-0.bini.default.svc.cluster.local:26257 | ff04cdd | 2021-02-04 09:34:47.053657 | 2021-02-05 02:45:31.756302 | true | true 2 | bini-2.bini.default.svc.cluster.local:26257 | ff04cdd | 2021-02-04 09:34:47.814316 | 2021-02-05 02:45:32.464036 | true | true 3 | bini-1.bini.default.svc.cluster.local:26257 | ff04cdd | 2021-02-04 09:34:47.077002 | 2021-02-05 02:45:31.756099 | true | true 4 | bini-3.bini.default.svc.cluster.local:26257 | ff04cdd | 2021-02-05 02:01:14.868258 | 2021-02-05 02:45:29.947311 | true | true (4 rows)
2.留神地址中编号最高的节点的ID(也就是上一步中蕴含bini-3的地址),并应用bini node decommission命令对其进行停用:
kubectl run bini -it \--image=bini:release2.0 \--rm \--restart=Never \-- node decommission <node ID> \--insecure \--host=bini-public
接下来,您将看到服役节点的状态:
id | is_live | replicas | is_decommissioning | is_draining +---+---------+----------+--------------------+-------------+ 4 | true | 28 | true | false节点齐全进行运行后,您将看到以下信息:id | is_live | replicas | is_decommissioning | is_draining +---+---------+----------+--------------------+-------------+ 4 | true | 0 | true | false (1 row)
No more data reported on target nodes. Please verify cluster health before removing the nodes.
3.从 StatefulSet 中移除一个节点:
$ kubectl scale statefulset bini --replicas=3statefulset "bini" scaled
三、滚动降级
$ kubectl patch statefulset bini -p '{"spec":{"template":{"spec":{"containers":[{"name":"bini","image":"bini:release2.0"}]}}}}'
四、删除集群
删除创立的所有资源
$ kubectl delete pods,statefulsets,services,persistentvolumeclaims,persistentvolumes,poddisruptionbudget,jobs -l app=binipod "bini-0" deletedpod "bini-1" deletedpod "bini-2" deletedpod "bini-3" deletedservice "bini" deletedservice "bini-public" deletedpersistentvolumeclaim "datadir-bini-0" deletedpersistentvolumeclaim "datadir-bini-1" deletedpersistentvolumeclaim "datadir-bini-2" deletedpersistentvolumeclaim "datadir-bini-3" deletedpoddisruptionbudget "bini-budget" deletedjob "cluster-init" deleted