Kubernetes in action-配置和应用升级

如有侵权，请联系～
如有错误，也欢迎批评指正～
本篇文章大部分是来自学习《Kubernetes in action》的笔记

1、配置

目前大家的共识：代码开发和配置是分离的。所以，k8s也提供了配置能力。通过命令行参数、环境变量、卷等方式给容器传递参数。
Kubernetes 中几种配置管理方式的区别与适用场景：

资源/机制	用途
ConfigMap	存储非敏感的键值对或文件内容，用于配置应用
Secret	存储敏感信息（如密码、密钥等），加密存储
Downward API	将 Pod 或容器的元数据注入到容器中（如 Pod 名称、IP 等），只能获取同一个pod中的数据
Kubernetes API	提供访问集群资源的接口（不是直接的配置注入方式），可以获取其他pod中的数据

1.1 configMap

✅ 用途：

• 存储 非敏感配置信息，比如：
  • 应用参数
  • 配置文件内容
  • 环境变量

✅ 使用方式：

• 作为环境变量注入容器；
• 挂载为 Volume 文件；

使用案例：
声明configMap

apiVersion: v1
kind: ConfigMap
metadata:name: app-config
data:greeting: "Hello from ConfigMap"timeout: "30s"

在pod中使用

env:- name: GREETINGvalueFrom:configMapKeyRef:name: app-configkey: greeting

1.2 secret

✅ 用途：

• 存储 敏感信息，如：
  • 密码
  • API token
  • SSH 私钥
  • TLS 证书

✅ 使用方式：

• 与 ConfigMap 类似，可以作为环境变量或 Volume 挂载；
• 内容默认是 Base64 编码，建议配合加密方案（如 KMS）使用。

使用案例：

kubectl create secret generic db-secret \--from-literal=username=admin \--from-literal=password=secret123

在pod中使用：

env:- name: DB_USERvalueFrom:secretKeyRef:name: db-secretkey: username

1.3 Downward API

✅ 用途：

• 将 Pod 或容器的元数据 注入到容器中，例如：
  • Pod 名称
  • Pod IP
  • 容器名
  • 命名空间
  • 资源限制和请求
  • 启动时间等

✅ 使用方式：

• 通过环境变量或 Volume 挂载的方式将这些信息传递给容器。

使用案例：

env:- name: POD_NAMEvalueFrom:fieldRef:fieldPath: metadata.name- name: POD_IPvalueFrom:fieldRef:fieldPath: status.podIP

在pod中使用：

volumes:- name: podinfodownwardAPI:items:- path: labelsfieldRef:fieldPath: metadata.labels- path: annotationsfieldRef:fieldPath: metadata.annotations

1.4 Kubernetes API

✅ 用途：

• 是一个 集群管理接口，允许你通过 RESTful API 访问和操作 Kubernetes 资源。
• 不是“配置注入”方式，而是用来进行编程化管理。

✅ 使用方式：

• 通过 kubectl、客户端库（如 client-go）、自定义控制器等方式调用；
• 适用于自动化运维、监控、调度等场景。

使用案例：

curl -k --header "Authorization: Bearer <token>" https://<apiserver>/api/v1/namespaces

2、服务升级

虽然需求的迭代，我们需要对已经部署的应用进行升级以满足产品诉求。当代码进行更新，重新docker build为新版本之后，如何将新的镜像文件部署到容器中代替原来的镜像文件。

2.1 升级方式

2.1.1 先删除所有的旧版pod，使用新版本pod替换

主要步骤：

• 修改rc的yaml文件，使用新的镜像，不需要修改rc的标签选择器
• 删除之前旧的pod资源
• rc会自动创建新的pod
  

优缺点：

• 优点：操作简单
• 缺点：下掉已经存在的pod，存在服务短期不可用

2.1.2 先创建新版pod，再删除旧版本pod

主要步骤：

• 修改rc的yaml文件，使用新的镜像，修改rc的标签选择器
• 将service的标签替换为新的标签
• 删除旧的pod
  
  短暂的需要2倍的pod资源。

2.1.3 滚动优化

主要步骤：

• 修改rc的yaml文件，pod增加一个标签deploy。service仍然能够指向原来的pod
• 创建一个新的rc，与原来的rc区别只是deploy值和镜像不一样，其他的都一样。例如app标签值一样。这样service可以同时管理这两个rc下的pod
• 逐渐删除旧的增加新的pod
  

replication controller升级最开始就是使用的这种方式。

kubectl rolling-update {rc原来的name} {rc新的name} --image={新的镜像}

这种方式不推荐的原因：这个升级过程【减少原容器，增加新容器】是由kubectl客户端进行控制，不是有k8s服务端控制。所以如果因为网络等原因，升级很容易处于中间状态。

2.2 使用deployment声明式升级应用

准备deployment资源yaml:

apiVersion: apps/v1
kind: Deployment
metadata:name: my-app
spec:replicas: 3selector:matchLabels:app: my-apptemplate:metadata:labels:app: my-appspec:containers:- name: my-containerimage: myregistry/myapp:v1.0.0ports:- containerPort: 8080

应用部署：

kubectl apply -f deployment.yaml

升级应用：

• 每次升级都会新创建replicaSet，旧的不会删除【用来回滚】
• deployment中的yaml中有两个属性：maxSurge、maxUnavailable属性控制滚动速度。

kubectl set image deployment/my-app my-container=myregistry/myapp:v1.1.0

回滚应用：

• 如果旧的replicaSet太多难以管理，可以通过deployment的revisionHistoryLimit属性设置保留多少个历史replicaSet.

// 查看升级历史
kubectl rollout history deployment/my-app
// 结果
REVISION  CHANGE-CAUSE
1         kubectl create --filename=deployment.yaml
2         kubectl set image ...// 回滚到指定版本
kubectl rollout undo deployment/my-app --to-revision=1