容器更新功能增强¶
https://blueprints.launchpad.net/tacker/+spec/enhancement-container-update
问题描述¶
在当前实现中，当用户调用 ConfigMaps 和 Secrets 的更新操作时，即使它们不使用这些更新的 ConfigMaps 和 Secrets，所有 Pod 都会被重启。此修改旨在移除此限制。
提议的变更¶
本规范提出以下变更
为容器更新操作[1]添加流程，仅重启使用更新的 ConfigMap 或 Secret 的 Pod。
ConfigMap 和 Secret 可以通过设置环境变量或挂载到卷的方式在 Pod 中使用。因此，搜索 ConfigMap 和 Secret 使用情况的键如下
对于 Pods，
spec.containers.env.valueFrom.configMapKeyRef.namespec.containers.env.valueFrom.secretKeyRef.namevolumes.configMap.namevolumes.secret.name
对于 Deployments, ReplicaSets 和 DaemonSets，
spec.template.spec.containers.env.valueFrom.configMapKeyRef.namespec.template.spec.containers.env.valueFrom.secretKeyRef.namespec.template.volumes.configMap.namespec.template.volumes.secret.name
注意
如果 manifest 文件中的镜像参数发生变化，Pod 将被替换，并且镜像将被更新。在这种情况下，无论 Pod 是否有需要更新的 ConfigMap 或 Secret，Pod 都会被替换。
操作设计¶
该图与容器更新[1]基本相同，除了只有使用更新的 ConfigMap 和 Secret 或其镜像已更改的 Pod 才会被选中进行替换。
以下是 VNF 修改信息操作的图表
+---------------+ +--------+
| Updated | | VNFD |
| manifest file | | |
+-------------+-+ +-+------+
| |
| |
+-v-----v--+ +------------------+
| CSAR | | Modify Request |
| | | with new vnfd_id |
+----+-----+ +-+----------------+
| | 1. Modify VNF Information request
| |
+-----+----------+----------------------------------------+
| | | VNFM |
| +--v----------v----------------+ |
| | Tacker-server | |
| +--+---------------------------+ |
| | 2. Modify VNF Information request |
| | |
+--------------------------+ | +--v------------------------------------------------+ |
| TackerDB | | | | |
| |4. Update vnfdId | | +----------------------+ | |
| <---------------------+--+----+ VnfLcmDriver | | |
| | | | | | | |
| |6. Update resourceId | | | | | |
| <---------------------+--+----+ | | |
| | | | | | | |
| <--+ | | | | | |
+--------------------------+ | | | +-+------------------+-+ | |
| 5-4. Select the | | |3. modify_start |5. modify_end | |
+--------------------------+ | Pod to | | | | | |
| | | replace | | +-v------------------v-+ | |
| +--------------------+ | +------------------+--+----+ MgmtDriver | | |
| | Kubernetes | | 5-1. Get the | | | |5-2. Select the | |
| | ConfigMap/Secret | | ConfigMap and | | | | ConfigMap and | |
| | | | Secret | | | | Secret to replace | |
| | <--+---------------------+--+----+ +---------------+ | |
| | | | | | | | | | |
| | | | 5-3. Replace config | | | | | | |
| | <--+---------------------+--+----+ <---------------+ | |
| +--------------------+ | | | | |5-6. Select the Pod | |
| | | | | | whose image has | |
| +--------------------+ | 5-5. Get the Pod | | | | changed | |
| | <--+---------------------+--+----+ +---------------+ | |
| | | | | | | | | | |
| | Kubernetes Pod | | 5-7. Replace Pod | | | | | | |
| | <--+---------------------+--+----+ <---------------+ | |
| | | | | | +----------------------+ | |
| | | | | | | |
| | | | | | Tacker-conductor | |
| +--------------------+ | | +---------------------------------------------------+ |
| | | |
| Kubernetes cluster | +---------------------------------------------------------+
+--------------------------+
+--------------------------+
| Hardware Resources |
+--------------------------+
操作请求参数¶
用户将以下修改参数提供给“PATCH /vnflcm/v1/vnf_instances/{vnfInstanceId}”作为 VnfInfoModificationRequest 数据类型
注意
请求参数未从现有的容器更新中更改。
属性名称 |
基数 |
参数描述 |
|---|---|---|
vnfInstanceName |
0..1 |
String. “vnfInstanceName” 属性在 “VnfInstance” 中。 |
vnfInstanceDescription |
0..1 |
String. “vnfInstanceDescription” 属性在 “VnfInstance” 中。 |
vnfdId |
0..1 |
Identifier. “vnfdId” 属性在 “VnfInstance” 中。 |
vnfConfigurableProperties |
0..1 |
KeyValuePairs. “vnfConfigurableProperties” 属性在 “VnfInstance” 中。 |
metadata |
0..1 |
KeyValuePairs. “metadata” 属性在 “VnfInstance” 中。 |
extensions |
0..1 |
KeyValuePairs. “extensions” 属性在 “VnfInstance” 中。 |
vimConnectionInfo |
0..N |
map (VimConnectionInfo). “vimConnectionInfo” 属性数组在 “VnfInstance” 中。 |
vimConnectionInfoDeleteIds |
0..N |
Identifier. 要从 “vimConnectionInfo” 属性数组中删除的 “VnfInstance”。 |
以下是请求体的示例
{
"vnfdId": "093c38b5-a731-4593-a578-d12e42596b3e"
}
在 Kubernetes 中使用 ConfigMap 和 Secret¶
ConfigMap 和 Secret 可以通过设置环境变量或挂载到卷的方式在 Pod 中使用。以下是在使用 ConfigMap 和 Secret 时的 Kubernetes 对象文件的示例。
注意
ConfigMap 和 Secret 的使用方式未从现有的容器更新中更改。
定义 Kubernetes ConfigMap 和 Secret 的示例文件
---
apiVersion: v1
kind: ConfigMap
metadata:
name: cm-data
data:
cmKey1.txt: |
configmap data
foo
bar
---
apiVersion: v1
kind: Secret
metadata:
name: secret-data
stringData:
password: 1mbb1G968fb1CUg
secKey1.txt: |
secret data
baz
将 ConfigMap 和 Secret 作为环境变量使用的 Kubernetes 对象文件的示例
apiVersion: v1
kind: Pod
metadata:
name: env-test
spec:
containers:
- image: alpine
name: alpine
env:
- name: CMENV
valueFrom:
configMapKeyRef:
name: cm-data
key: cmkey1.txt
- name: SECENV
valueFrom:
secretKeyRef:
name: secret-data
key: password
envFrom:
- prefix: CM_
configMapRef:
name: cm-data
- prefix: SEC_
secretRef:
name: secret-data
terminationGracePeriodSeconds: 0
通过挂载到卷的方式使用 ConfigMap 和 Secret 的 Kubernetes 对象文件的示例
apiVersion: v1
kind: Pod
metadata:
name: modify-VNF-volume-test
spec:
containers:
- image: alpine
name: alpine
volumeMounts:
- name: cm-volume
mountPath: /config
- name: sec-volume
mountPath: /etc/secrets
volumes:
- name: cm-volume
configMap:
name: cm-data
defaultMode: 0666
items:
- key: cmKey1.txt
path: cm/config.txt
- name: secret-volume
secret:
secretName: secret-data
defaultMode: 0600
items:
- key: secKey1.txt
path: creds/secret.txt
terminationGracePeriodSeconds: 0
操作顺序¶
客户端向“单个 VNF 实例”资源发送 PATCH 请求。
Tacker-conductor 将修改 VNF 请求发送到 VnfLcmDriver。
VnfLcmDriver 调用 MgmtDriver 的 modify_start。
VnfLcmDriver 将 VnfInstance.vnfdId 更新为 TackerDB 中新 VNFD 的 ID。
VnfLcmDriver 调用 MgmtDriver 的 modify_end。modify_end 使用 replace API 替换 ConfigMap、Secret 和 Pod。
5-1. MgmtDriver 发送请求以获取 ConfigMap 和 Secret 的信息到 VIM (Kubernetes)。
5-2. 如果 5-1 中检索到的信息与新信息不同，则 MgmtDriver 选择 ConfigMap 和 Secret。
注意
如果检索到的信息与新信息之间存在参数差异，则选择 ConfigMap 和 Secret 进行替换。
5-3. MgmtDriver 发送请求以将 5-2 中选择的 ConfigMap 和 Secret 的配置替换到 VIM (Kubernetes)。
5-4. MgmtDriver 发送请求以将使用旧 ConfigMap 或 Secret 的 Pod 选择到 TackerDB。
注意
检索具有在 5-2 中选择的 ConfigMap 和 Secret 名称的 Pod 的信息的理想方法是使用 Kubernetes 中实现的 field-selector 机制。但是，Kubernetes 的当前实现不支持 Proposed change 部分中描述的参数的 field-selectors。
5-5. MgmtDriver 发送请求以获取 Pod 的信息到 VIM (Kubernetes)。
5-6. MgmtDriver 选择其镜像已更改的 Pod。
5-7. MgmtDriver 发送请求以将 5-4 和 5-6 中选择的 Pod 替换到 VIM (Kubernetes)。
注意
如果 Pod、Deployment、ReplicaSet 和 DaemonSet 的 manifest 文件中的镜像参数发生变化，则在替换 Pod 时将替换镜像。如果 Pod 或 Deployment manifest 文件中发生镜像以外的参数更改，则不会应用更改。
VnfLcmDriver 将 VnfInstance.instantiatedVnfInfo.vnfcResourceInfo.computeResource.resourceId 更新为 TackerDB 中替换 Pod 的 ID。
备选方案¶
无
数据模型影响¶
无
REST API 影响¶
无
安全影响¶
无
通知影响¶
无
其他最终用户影响¶
无
性能影响¶
无
其他部署者影响¶
无
开发人员影响¶
无
实现¶
负责人¶
- 主要负责人
Masaki Ueno<masaki.ueno.up@hco.ntt.co.jp>
- 其他贡献者
Yusuke Niimi<niimi.yusuke@fujitsu.com>
Yoshiyuki Katada<katada.yoshiyuk@fujitsu.com>
Ayumu Ueha<ueha.ayumu@fujitsu.com>
工作项¶
为容器更新操作添加流程，仅重启使用更新的 ConfigMap 和 Secret 的 Pod。
依赖项¶
无
测试¶
将添加单元和功能测试，以涵盖规范所需的用例。
文档影响¶
将添加完整的用户指南，以从 VNF LCM API 的角度解释修改 VNF 信息。
