当前位置：首页 > news >正文

【运维篇】KubeSphere-02（经验汇总）

news 来源：原创 2025/8/26 7:48:29

一、使用建议

1.对于数据库、对像存储比较重的要不能丢失，有异地存储备份需求的有状态服务，不建议采用k8s进行部署，会导致运维难度更大。

2.对于中间件如redis、MQ、harbor、seata、nacos、zookeeper可采用k8s部署。

3.对于无状态服务tomcat、springboot、nginx、node等应用推荐都采用k8s部署。

4.对于应用配置中使用到的配置连接信息推荐采用域名方式配置，减少项目上的重复修改。

二、配置CoreDNS

在 Kubernetes 集群中，Pod 的 DNS 解析行为受 dnsPolicy 配置影响：

1. 默认策略：dnsPolicy: ClusterFirst

优先使用 Kubernetes 集群内部的 CoreDNS 服务进行解析。

如果内部解析失败，则会转发到上游 DNS 服务器（通常为宿主机的 DNS 配置）。

2. 自定义策略：dnsPolicy: None

Pod 可以指定自定义的 DNS 配置，包括 search 域名。

3. 主机配置的影响

如果宿主机 /etc/resolv.conf 文件中包含较多的 search 域，会导致 Pod 的 DNS 查询超时或失败。

2.1 通过命令方式配置

编辑coredns的配置字典（ConfigMap），增加hosts配置项，以下实现整个k8s中的服务通过ha.test.org域名请求至192.168.1.10这个IP，这里可以是我们的Haproxy代理服务器的VIP。

1.编辑配置

#在任意Master上执行，进入coredns编辑
kubectl edit configmap coredns -n kube-system

2.配置参考

编辑完成后切换到英文输入法，按Esc再输入:wq保存退出。

kind: ConfigMap
apiVersion: v1
metadata:name: corednsnamespace: kube-system
data:Corefile: |.:53 {errorshealth {lameduck 5s}readykubernetes cluster.local in-addr.arpa ip6.arpa {pods insecurefallthrough in-addr.arpa ip6.arpattl 30}hosts {192.168.1.10 ha.test.orgfallthrough}prometheus :9153forward . /etc/resolv.conf {max_concurrent 1000}cache 30loopreloadloadbalance}

3.重新创建cordns

kubectl rollout restart deployment coredns -n kube-system

2.2 通过管理界面配置

以管理员admin身份，登录kubesphere管理平台http://ip:30880/，选择集群管理>配置>配置字典，输入coredns进行查找。

1.选择集群管理

2.查找coredns配置

3.进入配置页

4.增加hosts配置

5.重新创建

三、配置时区

3.1 通过应用进行配置

1.在应用的value.xml中查找env环境指定时区

env:- name: TZvalue: "Asia/Shanghai"

3.2 通过管理平台配置

1.进入容器设置

2.设置环境变量

四、应用发布

4.1 中间件部署要求

1.对通用的中间件封装成标准的应用，放入私库进行快速部署，如redis、Mq、zookeeper等。

2.对于中间件每个项目都部署到同名的命名空间下，kubeSphere中创建的项目名称就是命名空间NameSpace。

3.对于中间件每个项目都取相同的名称。

通过以上三步，中间在每个项目中就有了唯一的访问路径，解决了在制作公司应用时，可以固定好中间件的配置文件信息。

4.2 中间件连接方式

4.2.1 服务介绍

在Kubernetes中，Headless Service和ClusterIP Service都是Service资源的类型，它们都用于为应用程序提供服务发现和负载均衡等功能。下面是Headless Service和ClusterIP Service的区别：

‌特性‌	‌Headless Service‌	‌VirtualIP（ClusterIP）‌
‌ClusterIP‌	不分配	分配固定虚拟 IP
‌负载均衡‌	无，客户端直接访问 Pod IP	由 kube-proxy 实现内部负载均衡
‌DNS 解析‌	返回所有 Pod IP 列表	解析为 ClusterIP
‌适用场景‌	有状态应用、需直接 Pod 访问	无状态应用、需统一入口和负载均衡
‌典型用例‌	数据库集群、分布式存储系统‌	微服务、Web 应用后端‌

4.2.2 过DNS访问

当创建一个Headless Service时，Kubernetes会为每个后端Pod创建一个对应的DNS A记录，使得可以直接通过Pod的名称进行访问。

#pod名称.服务名称.命名空间
<pod-name>.<service-name>.<name-space>

例如：如果有一个名为my-service的Headless Service，并且后端有三个Pod（pod-0、pod-1和pod-2），项目名称为com-sys，则可以通过以下方式来访问这些：

$ nslookup pod-0.my-service.com-sys
$ nslookup pod-1.my-service.com-sys
$ nslookup pod-2.my-service.com-sys

ClusterIP Service通常用于无状态应用程序的负载均衡场景，例如Web服务器、API服务器或者前端应用程序等。它可以通过Service关联的Endpoint对象来绑定后端Pod的IP地址和端口号，以实现对Pod的自动发现和管理。

#通过服务名称和命令空间直接访问
<service-name>.<name-space>

五、应用升级更新

5.1 静像拉取策略

静像拉取策略pullPolicy‌的三个选项关键差异总结：

‌策略‌	‌镜像更新控制‌	‌网络依赖‌	‌典型场景‌
`Always`	强（始终最新）	高	开发/测试环境‌
`IfNotPresent`	中（本地优先）	低	生产环境‌
`Never`	弱（仅限本地）	无	离线环境‌

5.2 Always更新

在项目前期因变更比较平凡，小的更新需要发布测试时可以不变更静像版本号，将应用的pullPolicy‌配置为Always，通过管理平台上的重新创建功能，自动拉取配置版本的最后推送的静像文件进行升级。

5.3 修改静像版本号更新

1.选择需要更新的部署，选择编辑YAML。

2.修改image的版本号，保存后开始自动更新，同样的方式也可以还原版本。

5.3 修改应用版本号更新

特别提醒：需要注意保持配置信息要与旧版本相同，该方式情况下应用、服务都会按新配置重新创建，原版本应用部署后再配置的磁盘挂载、环境变量配置、ClusterIp的外部访问都会重做，该方式下最好的方式就是所有的配置都要配置在应用配置文件中防止丢失。

1.选择应用下的编辑设置。

2.选择需要更新到的目标版本。

六、健康检测

针对项目应用我们都应该编写自已应用的可用性健康检测方法，并配置好应用的创建检测，以实现应用宕机时自动重启。

以下是WEB应用的健康检测示例：

七、日志查询

7.1 通过命令查看日志

# 查看所有pod
kubectl get pods -A
# 访问comm-sys空间下的zookeeper-0的日志
kubectl logs zookeeper-0 -n comm-sys

7.2 通过管理界面查看容器日志

7.3 通过日志管理平台查看日志

这里的功能需要安装kubesphere的日志系统（opensearch）对容器日志进行采集和存储。

7.3.1.进入日志页

7.3.2.日志汇总页

7.3.3.日志列表页

7.3.4.日志详情页

八、文件对拷

# 从容器中复制文件到主机
kubectl cp <some-namespace>/<some-pod>:/tmp/foo /tmp/bar# 从该机中复制文件到容器
kubectl cp /tmp/bar <some-namespace>/<some-pod>:/tmp/foo