前一篇文章《tidb-operator生产部署篇》已经完成了tidb-operator这个tidb集群管控工具以及生产环境tidb集群的部署，今天这篇文章继续讲述生产环境的tidb集群访问、集群扩缩容、集群升级等基本日常操作。
一、生产环境tidb访问
TiDB部署完成后要想访问有2项工作需要处理，分别是如何访问和集群初始化，下面分别来进行落地：
（1）如何访问生产环境TiDB？
如果是集群内访问分别是可以通过：pods ip、Service Cluster-IP、Service域名来访问
先看通过pods ip访问的：
:~# kubectl get pods -n tidb-test -o wide|grep tidb-test-tidb
tidb-test-tidb-0 2/2 Running 0 11d 10.xxx.xxx.1 db01 <none> <none>
tidb-test-tidb-1 2/2 Running 0 11d 10.xxx.xxx.162 db03 <none> <none>
tidb-test-tidb-2 2/2 Running 0 11d 10.xxx.xxx.183 db08 <none> <none>
:~# mysql -h 10.xxx.xxx.1 -uroot -p -P4000
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 50541114
Server version: 8.0.11-TiDB-v8.4.0 TiDB Server (Apache License 2.0) Community Edition, MySQL 8.0 compatible
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> select user();
+-------------------+
| user() |
+-------------------+
| root@10.101.232.2 |
+-------------------+
1 row in set (0.00 sec)
mysql> exit
Bye
然后基于Service Cluster-IP访问的
:~# kubectl get services -n tidb-test -o wide|grep tidb-test-tidb
tidb-test-tidb NodePort 172.xxx.xxx.213 <none> 4000:32569/TCP,10080:30286/TCP 11d app.kubernetes.io/component=tidb,app.kubernetes.io/instance=tidb-test,app.kubernetes.io/managed-by=tidb-operator,app.kubernetes.io/name=tidb-cluster
tidb-test-tidb-peer ClusterIP None <none> 10080/TCP 11d app.kubernetes.io/component=tidb,app.kubernetes.io/instance=tidb-test,app.kubernetes.io/managed-by=tidb-operator,app.kubernetes.io/name=tidb-cluster
root@db01:~# mysql -h 172.xxx.xxx.213 -uroot -p -P4000
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 2630038054
Server version: 8.0.11-TiDB-v8.4.0 TiDB Server (Apache License 2.0) Community Edition, MySQL 8.0 compatible
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> select user();
+-------------------+
| user() |
+-------------------+
| root@10.101.232.2 |
+-------------------+
1 row in set (0.00 sec)
mysql> exit
Bye
基于集群域名的访问，域名的组成方式：${service name}.${namespace}.svc.cluster.local
:~# mysql -h tidb-test-tidb-peer.tidb-test.svc.cluster.local -uroot -p -P4000
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 2630038118
Server version: 8.0.11-TiDB-v8.4.0 TiDB Server (Apache License 2.0) Community Edition, MySQL 8.0 compatible
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
mysql> select user();
+-------------------+
| user() |
+-------------------+
| root@10.101.232.2 |
+-------------------+
1 row in set (0.00 sec)
mysql> exit
Bye
生产环境建议用哪个？
回答这个生产环境访问的问题，我是建议用域名，因为一旦service被删除重建，Cluster-IP会发生变化业务如果写死的是具体的CLuster-IP，肯定会发生故障，如果基于域名方式访问则不会有问题。
（2）初始化权限和创建库表
默认部署完成的root数据库用户的密码为空，需要及时修改，另外就是给业务创建DB，创建业务账号和赋权，然后将域名、端口、数据库用户和密码发给用户使用即可。
mysql> set password for 'root'@'%' = 'xxxx';
mysql> create database user_db;
Query OK, 0 rows affected (0.51 sec)
mysql> create user user_db_sdml@`10.%` identified by 'xxxx';
Query OK, 0 rows affected (0.03 sec)
mysql> grant select,insert,update,delete on user_db.* to user_db_sdml@`10.%`;
Query OK, 0 rows affected (0.02 sec)
mysql> exit
Bye
二、生产环境tidb集群扩缩容的时机以及操作方式
k8s中的tidb集群扩缩容的命令很简单，但是我们需要知道什么情况下需要去操作，下面我列出几种需要操作的情景。
（1）通过监控查看大部分的tidb/tikv的CPU、内存、硬盘使用超过Qos配置limit上限的80%，这时就需要扩容。注意一些细节点：
- 首先是tidb/tikv的大部分节点，而不是某一个节点跑高，单节点负载过高大部分情况是热点，基本是可以通过重启解决。单region过热重启不管用，需要用tidb 6.0的内存表或者业务+DB的多层cache来解决，后面我可以写一篇热点处理的文章给大家详细介绍。
- 比如大部分tikv的存储使用超过80%，这时就需要及时扩容存储，如果使用的是动态PV，可以垂直扩容(500G->1024G)，如果基于local的物理ssd盘，就需要扩容replica数量，避免磁盘写满导致的业务问题。
- 大部分的扩容都是水平扩容，就是将8个tikv扩容到10个或者更多。但是还有一种就是垂直扩容，这种扩容一般都是单资源跑高，比如只有mem使用比较高，快超过limit阀值，有oom的风险，这时需要修改配置，调整内存限制就好，调整的过程自动触发tidb/tikv数据编号由大到小挨个重启。
（2）缩容的话就看资源使用率，一般都是初始化集群时因业务高估自己业务流量配置过大了。
- 比如底层局3个tikv，肯定不能缩容到2个（无法高可用），这时需要垂直降配(比如tikv之前配置20核100G内存，降低到12核心10G)。
- 另外大部分就是缩容tidb/tikv的数量，注意满足tidb集群高可用的最低配置数量
操作方式
其实就是调整tidb-test.yaml中的replicas(数量)，以及QOS部分（requests、limits），以tikv为例，我们要将tikv从3个扩容到5个，修改下面的replicas 3->5即可。如果要调整cpu限制需要修改request或者limits部分，比如我们想让tikv使用更多的CPU，就可以调整limits cpu 从14核心（14000m）到20核心，调整如下：
tikv:
baseImage: pingcap/tikv:v8.4.0
replicas: 5 #调整这里3->5
# if storageClassName is not set, the default Storage Class of the Kubernetes cluster will be used
storageClassName: local-storage
requests:
cpu: 6000m
memory: 12Gi
storage: 1760Gi
limits:
cpu: 20000m #这里调整14000->20000m
memory: 32Gi
storage: 1760Gi
修改后保存，然后执行应用即可
#kubectl apply -f tidb-test.yaml -n tidb-test
三、生产环境tidb集群升级
k8s环境下tidb集群升级的操作也非常简单。只需要修改tidb-test.yaml中的baseImage，生产环境建议下载对应的镜像到公司内部的镜像仓库，如果没有镜像仓库，需要k8s集群的nodes可访问外网(不太建议DB服务器出外网)，并且选择阿里云的镜像地址。
tidb:
baseImage: pingcap/tidb:v8.4.0 #修改之前的7.5.0->8.4.0
tikv:
baseImage: pingcap/tikv:v8.4.0 #修改之前的7.5.0->8.4.0
pd:
baseImage: pingcap/pd:v8.4.0 #修改之前的7.5.0->8.4.0
四、总结
k8s里面的tidb集群管理非常简单，就是一个yaml管所有，我们的扩缩容、升级等日常操作也就是维护tidb集群yaml变更，如果更好、更安全的变更？比如使用git来管理yaml，这样可以避免误删除，避免错误变更后无法回滚(因为修改保存后你不知道之前的配置了)，用git就可以完美解决变更风险管控问题，最终实现更快、更稳的tidb集群维护。