我正在使用带有Kubernetes 1.16的Helm v3.3.0。
集群已安装Kubernetes Service Catalog，因此可以将实现Open Service Broker API规范的外部服务实例化为K8S资源-ServiceInstance和ServiceBinding。
ServiceBinding反映为K8S Secret并包含创建的外部服务的绑定信息。这些秘密通常作为环境变量或卷在K8S Deployment中映射到Docker容器中。
现在我正在使用Helm部署我的Kubernetes资源，我读到here了...
Kubernetes类型的[Helm]安装顺序由kind_sorter.go中的枚举InstallOrder给出
在该文件中，该订单既未提及ServiceInstance也未提及ServiceBinding作为资源，这意味着Helm在安装了其任何之后安装了这些资源类型InstallOrder列表-特别是Deployment。这似乎与我的图表上运行的helm install --dry-run --debug的输出相匹配，该顺序指示K8S服务目录资源最后被应用。
问题：我不明白的是，为什么我的Deployment不能不能无法通过Helm安装。
毕竟我的Deployment资源似乎早于ServiceBinding就已经部署了。我的Secret引用的是ServiceBinding生成的Deployment。我希望它会失败，因为在安装Secret时Deployment还不存在。但是事实并非如此。
是只是时间故障/幸运的巧合，还是我可以依靠的东西？为什么？
谢谢！
答案 0 :(得分：1)
所以要回答我自己的问题（并感谢@ dawid-kruk和Slack上Service Catalog Sig的工作人员）：
<div id="root"></div>
<script src="https://cdnjs.cloudflare.com/ajax/libs/react/16.13.0/umd/react.production.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/react-dom/16.13.0/umd/react-dom.production.min.js"></script>（从Pod中创建的引用Secret的那些）的初始启动失败了！之所以失败，是因为K8S尝试启动Pod时实际上ServiceBinding不在。Secret终于出现时）将满足所有条件，以使Pod正常启动。因此，最终，evth。正在正常运行。如何精简呢？对于Helm，一种可能性是将自定义资源Secret和ServiceBinding包括在其可安装资源的有序列表中，并在安装阶段的早期进行安装。
但是即使没有这个，Kubernetes实际上也能很好地处理它。安装的顺序（在这种情况下）确实无关紧要。那是一件好事！
答案 1 :(得分：1)
正如我在评论中所说：
实际上，您的
Deployment从Status: CreateContainerConfigError开始就失败了。您的Deployment是在Secret的{{1}}之前创建的。只有ServiceBinding中的Secret可用时，它才能重新创建。
我想通过ServiceBinding为什么没有失败的示例来提供更多见识。
正在发生的事情（按顺序简化）：
Deployment->创建并产生一个Deployment Pod->由于缺少Pod而导致状态为CreateContainerConfigError的pod失败Secret->在后台创建ServiceBinding Secret获得必需的Pod并启动先前提到的Secret将对line 147发表评论，最后保留InstallOrder和ServiceInstace。
假设：
以下指南：
ServiceBinding目录中有一个Helm图表，其中包含以下文件：
templates/ ServiceInstance ServiceBinding 文件：
Deployment：
ServiceInstance.yaml apiVersion: servicecatalog.k8s.io/v1beta1
kind: ServiceInstance
metadata:
name: example-instance
spec:
clusterServiceClassExternalName: redis
clusterServicePlanExternalName: 5-0-4
：
ServiceBinding.yaml apiVersion: servicecatalog.k8s.io/v1beta1
kind: ServiceBinding
metadata:
name: example-binding
spec:
instanceRef:
name: example-instance
：
Deployment.yaml使用上述资源来检查正在发生的事情可以通过两种方式完成：
apiVersion: apps/v1
kind: Deployment
metadata:
name: ubuntu
spec:
selector:
matchLabels:
app: ubuntu
replicas: 1
template:
metadata:
labels:
app: ubuntu
spec:
containers:
- name: ubuntu
image: ubuntu
command:
- sleep
- "infinity"
# part below responsible for getting secret as env variable
env:
- name: DATA
valueFrom:
secretKeyRef:
name: example-binding
key: host
中的timestamp $ kubectl get RESOURCE -o yaml 如前所述，$ kubectl get RESOURCE --watch-only=true中的Pod无法启动，因为Deployment尝试生成时Secret不可用。 Pod可用后，Secret开始。
此Pod的状态如下：
Pod Pending ContainerCreating CreateContainerConfigError 这是一个时间戳为Running和Pod的表：
Secret您可以通过调用以下命令获取此时间戳：
| Pod | Secret |
|-------------------------------------------|-------------------------------------------|
| creationTimestamp: "2020-08-23T19:54:47Z" | - |
| - | creationTimestamp: "2020-08-23T19:54:55Z" |
| startedAt: "2020-08-23T19:55:08Z" | - |
$ kubectl get pod pod_name -n namespace -o yaml 您还可以通过以下方式获取其他信息：
$ kubectl get secret secret_name -n namespace -o yaml $ kubectl get event -n namespace 此方法需要运行Helm图表之前进行准备。打开另一个终端窗口（对于这种特殊情况2）并运行：
$ kubectl describe pod pod_name -n namespace $ kubectl get pod -n namespace --watch-only | while read line ; do echo -e "$(gdate +"%H:%M:%S:%N")\t $line" ; done 之后，应用您的Helm图表。
免责声明！
以上命令将监视资源的更改，并通过操作系统显示时间戳。请记住，此命令仅用于示例目的。
$ kubectl get secret -n namespace --watch-only | while read line ; do echo -e "$(gdate +"%H:%M:%S:%N")\t $line" ; done的输出：
Pod 21:54:47:534823000 NAME READY STATUS RESTARTS AGE
21:54:47:542107000 ubuntu-65976bb789-l48wz 0/1 Pending 0 0s
21:54:47:553799000 ubuntu-65976bb789-l48wz 0/1 Pending 0 0s
21:54:47:655593000 ubuntu-65976bb789-l48wz 0/1 ContainerCreating 0 0s
-> 21:54:52:001347000 ubuntu-65976bb789-l48wz 0/1 CreateContainerConfigError 0 4s
21:55:09:205265000 ubuntu-65976bb789-l48wz 1/1 Running 0 22s
的输出：
Secret其他资源：