Kubernetes in action-配置和应用升级

最新推荐文章于 2025-05-20 11:26:25 发布

啥都想学的又啥都不会的研究生

最新推荐文章于 2025-05-20 11:26:25 发布

阅读量1k

点赞数 6

文章标签： kubernetes 容器云原生 docker etcd 微服务 kubelet

本文链接：https://blog.csdn.net/m0_50149847/article/details/147931746

版权

Kubernetes的配置和应用升级

1、配置
2、服务升级

如有侵权，请联系～
如有错误，也欢迎批评指正～
本篇文章大部分是来自学习《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: GREETING
    valueFrom:
      configMapKeyRef:
        name: app-config
        key: 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_USER
    valueFrom:
      secretKeyRef:
        name: db-secret
        key: username

1.3 Downward API

✅ 用途：

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

✅ 使用方式：

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

使用案例：

env:
  - name: POD_NAME
    valueFrom:
      fieldRef:
        fieldPath: metadata.name
  - name: POD_IP
    valueFrom:
      fieldRef:
        fieldPath: status.podIP

在pod中使用：

volumes:
  - name: podinfo
    downwardAPI:
      items:
        - path: labels
          fieldRef:
            fieldPath: metadata.labels
        - path: annotations
          fieldRef:
            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: 3
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
        - name: my-container
          image: myregistry/myapp:v1.0.0
          ports:
            - 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