Hot answers tagged

2

You can use kubectl get -o json and parse the output using jq to iterate over the deployments, matching any desired configMapKeyRef.name and returning a uniq list of deployments. This should work: kubectl get deployments --all-namespaces -o json | jq -r '.items | map(select(.spec.template.spec.containers[]?.env[]?.valueFrom.configMapKeyRef.name == "...


2

YAML anchors are supported, but only for the same YAML file. You can't create the anchor (&) on a deployment file and reference (*) the value on another one. If you want to share ENVs values across multiple Deployments, you can create a ConfigMap with the ENVs and use the envFrom spec. Example: apiVersion: v1 kind: ConfigMap metadata: name: my-...


1

Do your instance groups have labels identifying the groups they belong to? If so, you can filter to them using the -l/--selector option, like so: kubectl top nodes --selector instance-group=group-1 This assumes that the label name is instance-group and the label value for the group you want to query is group-1.


1

I have come to the (preliminary) conclusion that this cannot be done. First, I had set the wrong idp-issuer-url. I had selected the IDP that normally serves during OIDC authentication to the Kubernetes cluster. But $token (or $CI_JOB_JWT in GitLab CI/CD parlance) was not generated there but by GitLab instead. Inspection e.g. at jwt.io indicates "iss&...


1

According the documentation you're giving, you need to remove run-build from the command : $ oc run NAME --image=<image> \ [--generator=<resource>] \ [--port=<port>] \ [--replicas=<replicas>] \ [--dry-run=<bool>] \ [--overrides=<inline_json>] \ [options]


1

I solved this temporarily with not the safest solution, but is working When creating secret with kops named admin, can use that to generate user field in exported kops config by adding also --admin in the export command


1

When I navigate to the URL, there do not appear to be any packages in the repo. Consider trying a mirror like: mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64


1

it seems you’re trying to change the config by setting a context and you’re not providing the config to the change context command. So do this kubectl config --kubeconfig=infra_k8/config.yaml use-context test-sim The setters are used when you want to add more entries to the config file, so you don’t need that command when changing context.


1

The best I have found so far for part 2 is to use the JSON output of get pods: kubectl get pods -o json | jq '.items[] | select(.metadata.labels."app.kubernetes.io/name") | { name: .metadata.labels."app.kubernetes.io/name", version: .metadata.labels."app.kubernetes.io/version" }' produces { "name": "db", "version": "0.0.1" } { "name": "app", "...


1

Not sure why this is required since Kubernetes is declarative and will not do anything is nothing has changed. Nonetheless, you can run it with the --server-dry-run=true flag. What attributes are going to be changed in the resource will not be mentioned but it does mention which resource(s) will be changed in the apply. You will need to parse the output ...


Only top voted, non community-wiki answers of a minimum length are eligible