K8S  Config应用配置小结

 更新时间:2025年03月10日 09:24:49   作者:野生的狒狒  
本文主要介绍了Kubernetes中ConfigMap和Secret的使用方法,以及如何在Pod和容器中进行资源配置,文中详细讲解了如何创建和使用ConfigMap来管理非机密性配置,以及如何使用Secret来存储敏感信息,同时,还介绍了如何在Pod中配置资源请求和限制,感兴趣的朋友一起看看吧

一、背景

在自动化流程中,对于一个应用来说,从开发阶段的配置管理,到制作容器镜像,再到最后通过K8S集群发布为服务,整个过程涉及到的配置非常多;

应用环境:通常是指代码层面的依赖配置,以常用的Nacos来说,通常会涉及框架、组件、自定义等几个层面的配置管理;

运行环境:以微服务架构来说,实际环境中需要管理多个应用的服务发布,在整个过程中必然会存在很多配置的管理,比如应用的资源分配、不同环境交互时的身份认证、敏感信息的安全管理等;

不论是应用还是运行层面的配置,都会涉及到一个基本的逻辑:配置可以抽取出来单独管理,在流程中直接引入该配置即可;

二、ConfigMap

ConfigMap用来将非机密性的数据保存到键值对中,Pod可以将其用作环境变量、命令行参数或者存储卷中的配置文件,会将环境配置信息和容器镜像解耦,便于应用配置的修改;

1、创建

ConfigMap中data字段用来保存UTF-8字符串,binaryData用来保存二进制数据作为base64编码的字串;

apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config-map
  namespace: default
data:
  active: test
  started: hello
  program: world

创建【ConfigMap】

kubectl apply -f app-config-map.yaml

查看【ConfigMap】

kubectl get cm/app-config-map -o yaml

K8S界面查看【ConfigMap】

2、使用

用法一:使用「app-config-map」中的值来配置【Pod】,在env中定义多个环境变量,但是值从ConfigMap中读取;

apiVersion: v1
kind: Pod
metadata:
  name: auto-client-one
spec:
  containers:
    - name: auto-client
      image: auto-client:1.1.3
      imagePullPolicy: Never
      ports:
        - containerPort: 8079
      env:
        - name: DATA_ACTIVE
          valueFrom:
            configMapKeyRef:
              name: app-config-map
              key: active
        - name: DATA_STARTED
          valueFrom:
            configMapKeyRef:
              name: app-config-map
              key: started
        - name: DATA_PROGRAM
          valueFrom:
            configMapKeyRef:
              name: app-config-map
              key: program

创建【Pod】

kubectl create -f auto-client-one.yaml

用法二:在【Pod】配置中,直接使用envFrom引入「app-config-map」,从而完成环境变量的设置;

apiVersion: v1
kind: Pod
metadata:
  name: auto-client-two
spec:
  containers:
    - name: auto-client
      image: auto-client:1.1.3
      imagePullPolicy: Never
      ports:
        - containerPort: 8079
      envFrom:
        - configMapRef:
            name: app-config-map

查看环境变量

# 1、执行该命令
kubectl exec -it auto-client-one -- bash
# 2、输入命令:env
env
# 3、打印的环境变量,只留下【app-config-map】配置的参数
DATA_ACTIVE=test
DATA_PROGRAM=world
DATA_STARTED=hello
# 4、查看【DATA_STARTED】的变量值
echo $DATA_STARTED

在【auto-client:1.1.3】容器镜像中,添加了一个输出环境变量的定时任务,通过查看运行日志,可以看到相关配置会被代码正确读取;

@Component
public class PrintEnvJob {
    private static final Logger LOG = LoggerFactory.getLogger(PrintEnvJob.class.getName()) ;
    @Scheduled(fixedDelay = 60000)
    public void systemData () {
        Map<String,String> envMap = System.getenv();
        for (Map.Entry<String, String> entry:envMap.entrySet()){
            String key = entry.getKey();
            String value = entry.getValue();
            LOG.info("【key:{},value:{}】",key,value);
        }
    }
}

【auto-client-one】日志输出

【auto-client-two】日志输出

注意事项

  • ConfigMap在设计上不是用来保存大量数据的,因此保存的数据不可超过1MiB
  • ConfigMap并不提供保密或者加密功能,如果存储的数据是机密的,可以使用Secret对象,或者使用其它方式确保数据的私密性;
  • ConfigMap中可以通过将immutable字段设置为true创建不可变更的配置,如果要修改只能删除后重建;

三、Secret

Secret是一种包含少量敏感信息例如密码、令牌或密钥的对象,这样的信息可能会被放在Pod规约中或者镜像中,使用Secret意味着不需要在应用程序代码中包含敏感数据;

1、创建

将【auto-client:1.1.3】镜像推送到云端的docker私有仓库里,并且删除本地相关镜像,测试下面的流程;

这里以最常见的镜像拉取场景来说,通常容器镜像文件是放在私有的云端仓库,K8S在访问时需要提供身份证明,可以通过Secret配置来处理该场景;

kubectl create secret docker-registry 【secret名称】 --docker-server=【仓库地址】 --docker-username=【用户名】 --docker-password=【密码】 --namespace=【命名空间】 -o yaml > cloud-registry-secret.yaml

2、使用

在上面配置了镜像拉取的Secret对象,在Pod层面使用imagePullSecrets来引用该对象,当从私有仓库拉取容器镜像时,节点上的kubelet能够完成与镜像仓库的身份认证;

apiVersion: apps/v1
kind: Deployment
metadata:
  name: auto-client-deployment
  labels:
    app: auto-client
spec:
  replicas: 1
  selector:
    matchLabels:
      app: auto-client
  template:
    metadata:
      labels:
        app: auto-client
    spec:
      imagePullSecrets:
        - name: cloud-registry-secret
      containers:
        - name: auto-client
          image: 【仓库地址】/auto-client:1.1.3
          imagePullPolicy: Always
          ports:
            - containerPort: 8079

注意事项

  • 默认情况下Secret未加密地存储在etcd中,任何拥有权限的用户都可以检索或修改Secret信息;
  • 每个Secret的大小最多为1MiB,施加这一限制是为了避免用户创建非常大的Secret,进而导致API服务器和kubelet内存耗尽;

四、Pod与容器

在定义Pod时可以选择性地为每个容器设定所需要的资源数量,最常见的可设定资源是CPU和内存大小,或者其他类型的资源,这样有利于调度器给Pod选择合适的节点;

apiVersion: apps/v1
kind: Deployment
metadata:
  name: auto-client-rs-deployment
  labels:
    app: auto-client
spec:
  replicas: 1
  selector:
    matchLabels:
      app: auto-client
  template:
    metadata:
      labels:
        app: auto-client
    spec:
      containers:
        - name: auto-serve
          image: auto-client:1.1.3
          imagePullPolicy: Never
          ports:
            - containerPort: 8079
          resources:
            requests:
              cpu: "250m"
              memory: "128Mi"
            limits:
              cpu: "500m"
              memory: "256Mi"

注意事项

  • CPU和内存统称为计算资源,计算资源的数量是可测量的,可以被请求、被分配、被消耗;
  • requests为容器指定资源需求,limits为容器设置资源限制;
  • 如果Pod运行所在节点有足够的可用资源,容器可以使用超出对应资源request属性所设置的资源量,但是不可以使用超出其资源limit属性所设置的资源量;

五、参考源码

文档仓库:
https://gitee.com/cicadasmile/butte-java-note
脚本仓库:
https://gitee.com/cicadasmile/butte-auto-parent

到此这篇关于K8S Config应用配置的文章就介绍到这了,更多相关K8S Config应用配置内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!

相关文章

  • Kubernetes中的service使用及说明

    Kubernetes中的service使用及说明

    Kubernetes Service通过固定IP和端口实现Pod的负载均衡和服务发现,解决动态IP问题,支持ClusterIP、NodePort、LoadBalancer等五种类型,适用于集群内通信、对外暴露及访问外部服务,结合Endpoints和负载均衡策略确保服务稳定性
    2025-10-10
  • Kubernetes集群调度详解(节点亲和性、Pod亲和性、Taint与Toleration)

    Kubernetes集群调度详解(节点亲和性、Pod亲和性、Taint与Toleration)

    Kubernetes调度器负责将Pod分配到节点,兼顾资源合理分配、调度效率及用户策略,通过预选、优选、选择三阶段决策,支持自定义调度器、节点亲和性(软硬策略)、Taint/Toleration机制及直接指定节点,实现灵活调度与容错
    2025-09-09
  • k8s容器资源限制方式

    k8s容器资源限制方式

    K8s通过request和limit管理容器资源,内存单位为字节,CPU为核心数,内存超限会终止容器,CPU超限不影响,LimitRange设namespace资源上下限,ResourceQuota限制总资源配额及Pod数量,二者均在创建时生效,不影响已有资源
    2025-07-07
  • K8S容器OOM killed排查过程

    K8S容器OOM killed排查过程

    这篇文章主要介绍了K8S容器OOM killed排查过程,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教
    2025-07-07
  • k8s高可用集群安装教程

    k8s高可用集群安装教程

    本文给大家介绍k8s高可用集群安装教程,本文通过图文示例相结合给大家介绍的非常详细,感兴趣的朋友一起看看吧
    2025-03-03
  • Istio 自动注入 sidecar 失败导致无法访问webhook服务的解决方法

    Istio 自动注入 sidecar 失败导致无法访问webhook服务的解决方法

    最近工作中在部署Istio环境的过程中发现官方示例启动的pod不能访问不到Istio的webhook,这个问题也是困扰了我一天,我把他归类到sidecar注入失败的情况下,本文给大家分享问题解决方法,感兴趣的朋友跟随小编一起看看吧
    2023-10-10
  • kubernetes k8s入门定义一个Pod

    kubernetes k8s入门定义一个Pod

    这篇文章主要为大家介绍了k8s入门定义一个Pod以及破底的定义内容详解,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多计步,早日升职加薪
    2022-03-03
  • K8S Operator部署及自定义详解

    K8S Operator部署及自定义详解

    这篇文章主要为大家介绍了K8S Operator部署及自定义详解,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多进步,早日升职加薪
    2023-04-04
  • 带你学会k8s 更高级的对象Deployment

    带你学会k8s 更高级的对象Deployment

    这篇文章主要为大家介绍了k8s还有更高级的"对象"Deployment使用示例详解,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多进步,早日升职加薪
    2023-04-04
  • 在K8s内部实现安全的网络隔离方式

    在K8s内部实现安全的网络隔离方式

    Kubernetes网络策略通过定义Pod之间的流量规则,实现安全隔离和最小权限访问,本文详细介绍了网络策略的基本概念、工作原理、配置方法及最佳实践,帮助构建更加安全的集群网络环境
    2026-01-01

最新评论