在 Kubernetes 中,ConfigMap 是一种 API 资源对象,用于存储非密钥/值数据,例如配置文件、环境变量和命令行参数等。
在更新 ConfigMap 之后,如果没有及时重启相关的 Pod 或者 Deployment,就有可能导致 Pod 配置不一致的问题。
ASP.NET Core默认的配置文件定义在appsetings.json和appsettings.{Environment}.json文件中。 这里面有一个问题就是,在使用容器部署时,每次修改配置文件都需要重新构建镜像。当然你也可能会说,我的配置文件很稳定不需要修改,但你又如何确保配置文件中一些机密配置的安全问题呢?比如暴露了你的远程数据库的连接信息,哪天被员工不小心删库跑路了呢? 那接下来就来讲解下如何在.NET Core 中正确使用ConfigMap。
在今天的文章中我将介绍Kubernetes中的ConfigMap对象。它的主要用途什么,为什么要用ConfigMap以及在Kubernetes里通常是如何使用ConfigMap的管理应用配置的。
很多生产环境中的应用程序配置较为复杂,可能需要多个config文件、命令行参数和环境变量的组合。使用容器部署时,把配置应该从应用程序镜像中解耦出来,以保证镜像的可移植性。尽管Secret允许类似于验证信息和秘钥等信息从应用中解耦出来,但在K8S1.2前并没有为了普通的或者非secret配置而存在的对象。在K8S1.2后引入ConfigMap来处理这种类型的配置数据。
ConfigMap 以一个或多个 key:value 的形式保存在 kubernetes 系统中供应用使用,既可以用于表示一个变量的值,也可以用于表示一个完整配置文件的内容。
ConfigMap Reloader 是一个 Kubernetes 的控制器,它可以监视 ConfigMap 的更改并自动更新与之关联的 Pod。当 ConfigMap 更改时,ConfigMap Reloader 将删除与之相关联的 Pod 中的卷,并重新创建一个新的 Pod,从而使应用程序使用新的配置文件。这种方法的好处是可以自动更新 Pod,无需手动更新或重启它们。
PS:ConfigMap是kubernetes的一个核心的概念,跟上次说的service一样,这个在实际的环境中使用很频繁。当ConfigMap以数据卷的形式挂载进Pod的时,这时更新ConfigMap(或删掉重建ConfigMap),Pod内挂载的配置信息会热更新。这时可以增加一些监测配置文件变更的脚本,然后reload对应服务。ConfigMap允许您将配置文件从容器镜像中解耦,从而增强容器应用的可移植性。
ConfigMap 是 Kubernetes 中一种用于存储配置数据的资源对象。它可以用来存储各种类型的数据,如环境变量、配置文件、命令行参数等。在 Kubernetes 集群中,ConfigMap 通常被用来存储应用程序的配置信息,以便应用程序可以在不同的环境中运行,而不需要修改代码。
ConfigMap 是一种 API 对象,用来将非机密性的数据保存到键值对中。使用时, Pods 可以将其用作环境变量、命令行参数或者存储卷中的配置文件。
ConfigMap 是一种 API 对象,用来将非机密性的数据保存到健值对中。使用时可以用作环境变量、命令行参数或者存储卷中的配置文件。
ConfigMap功能在Kubernetes1.2版本中引入,许多应用程序会从配置文件、命令行参数或环境变量中读取配置信息。 ConfigMap API给我们提供了向容器中注入配置信息的机制, ConfigMap可以被用来保存单个属性,也可以用来保存整个配置文件或者JSON二进制大对象
一旦创建了 ConfigMap,就可以在 Kubernetes Pod 中使用它。有两种方法可以使用 ConfigMap 中的配置数据:作为环境变量或作为卷。
ConfigMap了解 描述信息ConfigMap 功能在 Kubernetes1.2 版本中引入,许多应用程序会从配置文件、命令行参数或环境变量中读取配置信息。ConfigMap API 给我们提供了向容器中注入配置信息的机制,ConfigMap 可以被用来保存单个属性,也可以用来保存整个配置文件或者 JSON 二进制大对象
笔记分享 | Note Share No matter where I am, I will reply you immediately when I see the email.My Email: echo "YUBzYW1lZ28uY29tCg==" | base64 -d 目的 应用程序部署的信息和程序进行模块分离 特点 生成为容器内的环境变量 设置容器启动的命令参数 volume 形式挂载成容器内的文件或目录 示例 使用文件创建 configmap # 创建 configmap ➜ ku
笔记分享 | Note ShareNo matter where I am, I will reply you immediately when I see the email.My Email:echo "YUBzYW1lZ28uY29tCg==" | base64 -d 目的 应用程序部署的信息和程序进行模块分离 特点 生成为容器内的环境变量 设置容器启动的命令参数 volume 形式挂载成容器内的文件或目录 示例 使用文件创建 configmap # 创建 configmap ➜ kubectl cr
大家好, 我是 老麦, 一个运维老兵, 现在专注于 Golang,DevOps,云原生基础设施建设。
对于上一篇文章我们分享了为什么要使用 ConfigMap ,我们创建 ConfigMap 的时候可以传入单个或者多个键值对,也可以传入文件,还分享了如何简单的传入 ConfigMap 里面的数据作为环境变量
不论什么样的应用,基本都有配置文件,在企业中,大部分会用到配置中心,比如apollo、nacos等,也有一些公司直接使用Kubernetes自带的配置管理,主要有:
将 spring boot 项目部署在 k8s 上,需要打镜像,为了实现配置文件可配置,就需要将配置文件与镜像解耦。
我们知道,在几乎所有的应用开发中,都会涉及到配置文件的变更,比如说在web的程序中,需要连接数据库,缓存甚至是队列等等。而我们的一个应用程序从写第一行代码开始,要经历开发环境、测试环境、预发布环境只到最终的线上环境。而每一个环境都要定义其独立的各种配置。如果我们不能很好的管理这些配置文件,你的运维工作将顿时变的无比的繁琐。为此业内的一些大公司专门开发了自己的一套配置管理中心,如360的Qcon,百度的disconf等。kubernetes也提供了自己的一套方案,即ConfigMap。kubernetes通过ConfigMap来实现对容器中应用的配置管理。
我们在开发过程中,可能需要开发一个类似Deployment的资源逻辑,管理依赖资源是控制器的基础,如果不能观察它们的状态变化就不可能管理它们。这就意味着,我们需要 reconciler 能监控多个资源的变化。
通过 docker desktop 可以安装适用于单机和开发环境单机版的 K8S,如果 docker desktop 无法启动 Kubernates 通过以下方式解决:
在应用启动过程中需要一些敏感信息,比如数据库用户名、密码,如果直接明文存储在容器镜像中是不安全的,K8S提供的方案是Secret。
在 Kubernetes 中,ConfigMap 是用来存储配置信息的资源对象。当我们需要更改应用程序的配置时,我们可以通过更新 ConfigMap 来实现。然而,在 Kubernetes 中更新 ConfigMap 不会自动更新 Pod 中使用的配置信息,这就需要我们手动更新或重启 Pod,以便它们使用新的配置。这可能会导致服务中断或不可用,从而影响用户体验。因此,我们需要一种方法来实现 ConfigMap 的热更新,以便在不中断服务的情况下更新应用程序的配置。
指定了items将会只创建指定的配置文件,如果不指定items,将会configMap中所有的配置项都分别创建配置文件。
● 在前面已经提到,容器的生命周期可能很短,会被频繁的创建和销毁。那么容器在销毁的时候,保存在容器中的数据也会被清除。这种结果对用户来说,在某些情况下是不乐意看到的。为了持久化保存容器中的数据,kubernetes引入了Volume的概念。
configmap是k8s的一个配置管理组件,可以将配置以key-value的形式传递,通常用来保存不需要加密的配置信息,加密信息则需用到Secret,主要用来应对以下场景:
ConfigMap作为Kubernetes中配置资源存储对象,通过ConfigMap可以存储各种各样的配置文件,具体使用方式: 深入探究 K8S ConfigMap 和 Secret,但在使用过程中会碰到各种不方便,一般情况下,特别是没有接入分布式配置中心的服务,配置文件是存储在服务所在特定目录下,这就导致需要我们把配置copy或者load到Kubernetes ConfigMap配置资源对象中,因为ConfigMap使用yaml格式进行存储,改变原来的使用习惯,使用和修改过程中难免出错,于是就引入了ConfigMapGenerator, 它是Kustomize ConfigMap自动生成配置插件,使用方式非常简单,如下图所示:
如启用一个mysql容器,mysql容器重要的文件有两部分,一部分为存储数据文件,一部分为配置文件my.cnf,存储数据可以用持久存储实现和容器的分离解耦,配置文件也能够实现和容器的分离解耦,也就是说mysql容器能够直接读取并使用预先配置好的配置文件(而不是使用容器中默认自带的配置文件).这就是configMap的功能。
今天我们来分享 ConfigMap 资源,分享之前,我们来看看前面我们跑应用程序都是怎么玩的
在应用部署时,配置文件几乎是绕不开的,通常我们是把配置文件放置在指定目录下,通过配置文件使应用修改的灵活性更高。但是如果我们把应用打包成容器镜像后,容器内的镜像文件就不容易修改了,一般我们会采用以下方式修改容器中的配置文件:
前言:在之前的文档中,我们介绍过 secret 的使用,与其同类型的资源还有 configmap ,这里我们会简单介绍一下configmap, 以及分析 cofigmap 和 secret 在功能 和 使用场景上的区别。
在实际的线上场景中,我们并不能在配置 Pod 的 yaml 里描述所有需要的信息,因为总有一些信息或因为其保密性,或因为其动态变化性,是不能够放在配置文件里的,那么,这类信息要怎么加入到我们的 Pod 配置体系中呢?
这kubernetes中,这类Volume不是为了存放数据,也不是用来做数据交换,而是为容器提供预先定义好的数据。所以从容器角度来看,这类Volume就像是被投射进容器一样。
配置中心在微服务的服务治理场景基本上是属于标配,常见可以用来做配置中心有nacos、apollo、zookeeper、springcloud config、consul、etcd、redis、disconf、dimond、xxl-conf等。这些组件的特点都是需要安装,如果大家的部署环境中有用到k8s,且不需要用到太多配置中心的特殊功能,比如灰度发布、权限管理、发布审核、操作审计啥的,仅仅只是用来统一配置,以及实现配置的热更新,那今天讲主角configMap会是一个挺不错的选择
K8sService能够提供很强大的功能,通过提供ClusterIP可以作为Pod的对外访问接口,并提供软负载均衡。但是Service的ClusterIP地址只能在集群内部访问,如何让集群外部的用户访
基于centos7.9,docker-ce-20.10.18,kubelet-1.22.3-0
有了前面两张的铺垫, 今天这个很简单。 我们说说另外一种为容器注入环境变量的方式。
如果需要向容器传递参数,可以在Yaml文件中通过command和args或者环境变量的方式实现。
在 Kubernetes 中,当一个 Pod 中需要挂载多个 Volume 时,可以使用 SubPath 来指定不同的 Volume 中的不同文件或目录挂载到容器中的不同路径上,从而更加灵活地使用 Volume。本文将介绍如何使用 SubPath 来挂载多个 Volume。
比如我们需要从.Values中读取的值变成字符串的时候就可以通过调用quote模板函数来实现:(templates/configmap.yaml)
在部署应用程序时,我们都会涉及到应用的配置,在容器中,如Docker容器中,如果将配置文件打入容器镜像,这种行为等同于写死配置,每次修改完配置,镜像就得重新构建。当然,我们也可以通过挂载包含该文件的卷进行配置管理和修改。而在k8s中,我们要讲一种更好的方式,即ConfigMap,这种资源对象的出现,更是极大的方便了应用程序的配置管理。 ConfigMap是一个或多个key/value的形式保存在k8s中,内部可以管理变量也可以管理完整的配置文件内容。
许多容器会从配置文件、命令行参数或环境变量中读取配置信息,这些配置信息可以通过configmap达到解耦目的,同一配置管理
ConfigMap 和 Secret 是 Kubernetes 中两个重要的对象,它们用于管理应用程序所需的配置信息和敏感数据。虽然它们是非常有用的工具,但它们也有一些使用限制
一个常见问题是:如何处理不同环境下不同的配置?传统的解决方案是为每个环境都单独设置一个配置文件,比如 rails 项目里一般会有 development、production、test 等几个配置文件,不过此方法不易扩展:更多部署意味着更多新的环境,随着项目的不断深入,开发人员可能还会添加他们自己的环境,这将导致各种配置组合的激增,从而给管理部署增加了很多不确定因素,此外,直接在文件中保存配置的话,如果有用户名密码等敏感信息,往往意味着它们会一并被保存到版本库中,这可能会诱发安全隐患,类似的案例在 github 上已经数不胜数了。关于此类问题,12factor 给出的解决方案是在环境变量中保存配置,如此一来,代码层面上就不用再关注不同环境下配置的差异了,版本库里也不用保存敏感信息了(都保存到环境变量里面了)。
还是老规矩先来了解下什么是ConfigMap,那么在了解ConifigMap的同时也得了解下另一个概念就是Secret。可能会有人说,你这不是在讲ConfigMap么,怎么还要扯Secret,别着急等我慢慢道来,那为什么要有这两个东西呢?因为在实际应用的过程中,我们经常会需要传一些配置给我们的应用,比如配置文件变更啊、用户名密码啊等等之类的。可能这个时候就会有童鞋说了我们有好多种方案可以实现啊,比如:
kubectl exec -it my-pod --container main-app -- /bin/bash
K8s提供了多种外部数据注入容器的方式,今天我们主要学习环境变量、ConfigMap以及Secret的使用和配置。
领取专属 10元无门槛券
手把手带您无忧上云