在以下情况下,我在../base/中定义了我的容器。
在这个/ dev /目录中,我想开始命名空间dev中的所有部署和状态集。
问题在于,我还想在local-path-storage命名空间中运行local-path-storage CSI。 kustomize将覆盖它,并在“ dev”命名空间中创建它。
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
namespace: dev
bases:
- ../base
resources:
- local-path-storage.yaml
如何仅对local-path-storage.yaml撤消命名空间覆盖?
答案 0 :(得分:2)
该功能在Kustomize中尚不存在。有open issue解决了这个问题,但在撰写本文时还没有开放的PR。
这里最快的解决方案是删除namespace
中的dev/kustomize.yaml
设置,并手动设置dev
中所有资源中的命名空间。
从我先前提到的问题中无耻地复制的另一种选择是创建一个转换器来解决此问题:
#!/usr/bin/env /usr/bin/python3
import sys
import yaml
with open(sys.argv[1], "r") as stream:
try:
data = yaml.safe_load(stream)
except yaml.YAMLError as exc:
print("Error parsing NamespaceTransformer input", file=sys.stderr)
# See kubectl api-resources --namespaced=false
blacklist = [
"ComponentStatus",
"Namespace",
"Node",
"PersistentVolume",
"MutatingWebhookConfiguration",
"ValidatingWebhookConfiguration",
"CustomResourceDefinition",
"APIService",
"MeshPolicy",
"TokenReview",
"SelfSubjectAccessReview",
"SelfSubjectRulesReview",
"SubjectAccessReview",
"CertificateSigningRequest",
"ClusterIssuer",
"BGPConfiguration",
"ClusterInformation",
"FelixConfiguration",
"GlobalBGPConfig",
"GlobalFelixConfig",
"GlobalNetworkPolicy",
"GlobalNetworkSet",
"HostEndpoint",
"IPPool",
"PodSecurityPolicy",
"NodeMetrics",
"PodSecurityPolicy",
"ClusterRoleBinding",
"ClusterRole",
"ClusterRbacConfig",
"PriorityClass",
"StorageClass",
"VolumeAttachment",
]
try:
for yaml_input in yaml.safe_load_all(sys.stdin):
if yaml_input['kind'] not in blacklist:
if "namespace" not in yaml_input["metadata"]:
yaml_input["metadata"]["namespace"] = data["namespace"]
print("---")
print(yaml.dump(yaml_input, default_flow_style=False))
except yaml.YAMLError as exc:
print("Error parsing YAML input\n\n%s\n\n" % input, file=sys.stderr)
答案 1 :(得分:2)
不幸的是,在kustomization中覆盖名称空间是不可能的,它假定所有资源都应属于同一名称空间。
您的替代方案是:
kubectl apply -f .
我通常为每组资源创建一个kustomization,将它们一起部署在命名空间中,以使kustomization简单且独立于任何其他资源。
答案 2 :(得分:1)
我也面临同样的问题。
我解决这个问题的方法是将其分解为多个步骤。
我会有 stepone、steptwo 文件夹。
tree ./project/
./project/
├── stepone
│ ├── base
│ └── overlay
└── steptwo
├── base
└── overlay
现在我可以将不应覆盖命名空间的部署部分移到 steptwo 中,反之亦然。取决于您的部署需求。 我正在处理来自 heml 模板的复杂转换,模板输出了 200 多个文件。
我只是将部署分解为不同的步骤,并在每个步骤中使用 kustomize 来管理需要隔离的部署部分。
它确实增加了一些努力,但它仍然提供了我需要的隔离,直到 kustomize 找到处理命名空间覆盖的这种复杂性的好方法。这需要 @Diego-mendes 个答案并将不同的部分封装到它们自己的文件夹中。