ConfigMap

ConfigMap 是一種 API 對象，用來將非機(jī)密性的數(shù)據(jù)保存到鍵值對中。使用時， Pods 可以將其用作環(huán)境變量、命令行參數(shù)或者存儲卷中的配置文件

ConfigMap 將你的環(huán)境配置信息和 容器鏡像 解耦，便于應(yīng)用配置的修改

說明：
ConfigMap 并不提供保密或者加密功能。 如果你想存儲的數(shù)據(jù)是機(jī)密的，請使用 Secret， 或者使用其他第三方工具來保證你的數(shù)據(jù)的私密性，而不是用 ConfigMap

動機(jī)

使用 ConfigMap 來將你的配置數(shù)據(jù)和應(yīng)用程序代碼分開

比如，假設(shè)你正在開發(fā)一個應(yīng)用，它可以在你自己的電腦上（用于開發(fā)）和在云上 （用于實際流量）運行。 你的代碼里有一段是用于查看環(huán)境變量 DATABASE_HOST，在本地運行時， 你將這個變量設(shè)置為 localhost，在云上，你將其設(shè)置為引用 Kubernetes 集群中的 公開數(shù)據(jù)庫組件的 服務(wù)

這讓你可以獲取在云中運行的容器鏡像，并且如果有需要的話，在本地調(diào)試完全相同的代碼

ConfigMap 在設(shè)計上不是用來保存大量數(shù)據(jù)的。在 ConfigMap 中保存的數(shù)據(jù)不可超過 1 MiB。如果你需要保存超出此尺寸限制的數(shù)據(jù)，你可能希望考慮掛載存儲卷 或者使用獨立的數(shù)據(jù)庫或者文件服務(wù)

ConfigMap 對象

ConfigMap 是一個 API 對象， 讓你可以存儲其他對象所需要使用的配置。 和其他 Kubernetes 對象都有一個 spec 不同的是，ConfigMap 使用 data 和 binaryData 字段。這些字段能夠接收鍵-值對作為其取值。data 和 binaryData 字段都是可選的。data 字段設(shè)計用來保存 UTF-8 字符串，而 binaryData 則被設(shè)計用來保存二進(jìn)制數(shù)據(jù)作為 base64 編碼的字串

ConfigMap 的名字必須是一個合法的 DNS 子域名

data 或 binaryData 字段下面的每個鍵的名稱都必須由字母數(shù)字字符或者 -、_ 或 . 組成。在 data 下保存的鍵名不可以與在 binaryData 下出現(xiàn)的鍵名有重疊

從 v1.19 開始，你可以添加一個 immutable 字段到 ConfigMap 定義中， 創(chuàng)建不可變更的 ConfigMap

ConfigMaps 和 Pods

你可以寫一個引用 ConfigMap 的 Pod 的 spec，并根據(jù) ConfigMap 中的數(shù)據(jù)在該 Pod 中配置容器。這個 Pod 和 ConfigMap 必須要在同一個 名字空間 中

示例 它的一些鍵只有一個值，其他鍵的值看起來像是 配置的片段格式

apiVersion: v1
kind: ConfigMap
metadata:
  name: game-demo
data:
  # 類屬性鍵；每一個鍵都映射到一個簡單的值
  player_initial_lives: "3"
  ui_properties_file_name: "user-interface.properties"

  # 類文件鍵
  game.properties: |
    enemy.types=aliens,monsters
    player.maximum-lives=5    
  user-interface.properties: |
    color.good=purple
    color.bad=yellow
    allow.textmode=true  

你可以使用四種方式來使用 ConfigMap 配置 Pod 中的容器：

1、在容器命令和參數(shù)內(nèi)
2、容器的環(huán)境變量
3、在只讀卷里面添加一個文件，讓應(yīng)用來讀取
4、編寫代碼在 Pod 中運行，使用 Kubernetes API 來讀取 ConfigMap
這些不同的方法適用于不同的數(shù)據(jù)使用方式。 對前三個方法，kubelet 使用 ConfigMap 中的數(shù)據(jù)在 Pod 中啟動容器

第四種方法意味著你必須編寫代碼才能讀取 ConfigMap 和它的數(shù)據(jù)。然而， 由于你是直接使用 Kubernetes API，因此只要 ConfigMap 發(fā)生更改， 你的應(yīng)用就能夠通過訂閱來獲取更新，并且在這樣的情況發(fā)生的時候做出反應(yīng)。 通過直接進(jìn)入 Kubernetes API，這個技術(shù)也可以讓你能夠獲取到不同的名字空間里的 ConfigMap

下面是一個 Pod 的示例，它通過使用 game-demo 中的值來配置一個 Pod

apiVersion: v1
kind: Pod
metadata:
  name: configmap-demo-pod
spec:
  containers:
    - name: demo
      image: alpine
      command: ["sleep", "3600"]
      env:
        # 定義環(huán)境變量
        - name: PLAYER_INITIAL_LIVES # 請注意這里和 ConfigMap 中的鍵名是不一樣的
          valueFrom:
            configMapKeyRef:
              name: game-demo           # 這個值來自 ConfigMap
              key: player_initial_lives # 需要取值的鍵
        - name: UI_PROPERTIES_FILE_NAME
          valueFrom:
            configMapKeyRef:
              name: game-demo
              key: ui_properties_file_name
      volumeMounts:
      - name: config
        mountPath: "/config"
        readOnly: true
  volumes:
  # 你可以在 Pod 級別設(shè)置卷，然后將其掛載到 Pod 內(nèi)的容器中
  - name: config
    configMap:
      # 提供你想要掛載的 ConfigMap 的名字
      name: game-demo
      # 來自 ConfigMap 的一組鍵，將被創(chuàng)建為文件
      items:
      - key: "game.properties"
        path: "game.properties"
      - key: "user-interface.properties"
        path: "user-interface.properties"

ConfigMap 不會區(qū)分單行屬性值和多行類似文件的值，重要的是 Pods 和其他對象如何使用這些值。

上面的例子定義了一個卷并將它作為 /config 文件夾掛載到 demo 容器內(nèi)， 創(chuàng)建兩個文件，/config/game.properties 和 /config/user-interface.properties， 盡管 ConfigMap 中包含了四個鍵。 這是因為 Pod 定義中在 volumes 節(jié)指定了一個 items 數(shù)組。 如果你完全忽略 items 數(shù)組，則 ConfigMap 中的每個鍵都會變成一個與該鍵同名的文件， 因此你會得到四個文件

使用 ConfigMap

ConfigMap 可以作為數(shù)據(jù)卷掛載。ConfigMap 也可被系統(tǒng)的其他組件使用， 而不一定直接暴露給 Pod。例如，ConfigMap 可以保存系統(tǒng)中其他組件要使用的配置數(shù)據(jù)

ConfigMap 最常見的用法是為同一命名空間里某 Pod 中運行的容器執(zhí)行配置。 你也可以單獨使用 ConfigMap

比如，你可能會遇到基于 ConfigMap 來調(diào)整其行為的 插件 或者 operator

在 Pod 中將 ConfigMap 當(dāng)做文件使用

要在一個 Pod 的存儲卷中使用 ConfigMap:
1、創(chuàng)建一個 ConfigMap 對象或者使用現(xiàn)有的 ConfigMap 對象。多個 Pod 可以引用同一個 ConfigMap
2、修改 Pod 定義，在 spec.volumes[] 下添加一個卷。 為該卷設(shè)置任意名稱，之后將 spec.volumes[].configMap.name 字段設(shè)置為對你的 ConfigMap 對象的引用
3、為每個需要該 ConfigMap 的容器添加一個 .spec.containers[].volumeMounts[]。 設(shè)置 .spec.containers[].volumeMounts[].readOnly=true 并將 .spec.containers[].volumeMounts[].mountPath 設(shè)置為一個未使用的目錄名， ConfigMap 的內(nèi)容將出現(xiàn)在該目錄中
4、更改你的鏡像或者命令行，以便程序能夠從該目錄中查找文件。ConfigMap 中的每個 data 鍵會變成 mountPath 下面的一個文件名。

示例

apiVersion: v1
kind: Pod
metadata:
  name: mypod
spec:
  containers:
  - name: mypod
    image: redis
    volumeMounts:
    - name: foo
      mountPath: "/etc/foo"
      readOnly: true
  volumes:
  - name: foo
    configMap:
      name: myconfigmap

如果 Pod 中有多個容器，則每個容器都需要自己的 volumeMounts 塊，但針對每個 ConfigMap，你只需要設(shè)置一個 spec.volumes 塊

被掛載的 ConfigMap 內(nèi)容會被自動更新

當(dāng)卷中使用的 ConfigMap 被更新時，所投射的鍵最終也會被更新。 kubelet 組件會在每次周期性同步時檢查所掛載的 ConfigMap 是否為最新。 不過，kubelet 使用的是其本地的高速緩存來獲得 ConfigMap 的當(dāng)前值。 高速緩存的類型可以通過 KubeletConfiguration 結(jié)構(gòu). 的 configMapAndSecretChangeDetectionStrategy 字段來配置

ConfigMap 既可以通過 watch 操作實現(xiàn)內(nèi)容傳播（默認(rèn)形式），也可實現(xiàn)基于 TTL 的緩存，還可以直接經(jīng)過所有請求重定向到 API 服務(wù)器。 因此，從 ConfigMap 被更新的那一刻算起，到新的主鍵被投射到 Pod 中去， 這一時間跨度可能與 kubelet 的同步周期加上高速緩存的傳播延遲相等。 這里的傳播延遲取決于所選的高速緩存類型 （分別對應(yīng) watch 操作的傳播延遲、高速緩存的 TTL 時長或者 0）

以環(huán)境變量方式使用的 ConfigMap 數(shù)據(jù)不會被自動更新。 更新這些數(shù)據(jù)需要重新啟動 Pod

不可變更的 ConfigMap

Kubernetes 特性 Immutable Secret 和 ConfigMaps 提供了一種將各個 Secret 和 ConfigMap 設(shè)置為不可變更的選項。對于大量使用 ConfigMap 的集群 （至少有數(shù)萬個各不相同的 ConfigMap 給 Pod 掛載）而言，禁止更改 ConfigMap 的數(shù)據(jù)有以下好處：

• 保護(hù)應(yīng)用，使之免受意外（不想要的）更新所帶來的負(fù)面影響
• 通過大幅降低對 kube-apiserver 的壓力提升集群性能， 這是因為系統(tǒng)會關(guān)閉對已標(biāo)記為不可變更的 ConfigMap 的監(jiān)視操作

此功能特性由 ImmutableEphemeralVolumes 特性門控來控制。 你可以通過將 immutable 字段設(shè)置為 true 創(chuàng)建不可變更的 ConfigMap

例如：

apiVersion: v1
kind: ConfigMap
metadata:
  ...
data:
  ...
immutable: true

一旦某 ConfigMap 被標(biāo)記為不可變更，則 無法 逆轉(zhuǎn)這一變化，，也無法更改 data 或 binaryData 字段的內(nèi)容。你只能刪除并重建 ConfigMap。 因為現(xiàn)有的 Pod 會維護(hù)一個已被刪除的 ConfigMap 的掛載點，建議重新創(chuàng)建這些 Pods文章來源地址http://www.zghlxwxcb.cn/news/detail-607391.html

到了這里，關(guān)于【云原生】Kubernetes之ConfigMap的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！