Labels vs annotations

/*@jsxRuntime automatic @jsxImportSource react*/
const {useMDXComponents: _provideComponents} = arguments[0];
function _createMdxContent(props) {
  const _components = Object.assign({
    p: "p",
    pre: "pre",
    code: "code",
    h2: "h2",
    h3: "h3",
    ul: "ul",
    li: "li",
    a: "a"
  }, _provideComponents(), props.components), {OpenShiftLocal, KubeBadge} = _components;
  if (!KubeBadge) _missingMdxReference("KubeBadge", true);
  if (!OpenShiftLocal) _missingMdxReference("OpenShiftLocal", true);
  return <><_components.p>{"When describing pods and other resources, you can see two sets of key value pairs. One is called Labels and the other Annotations."}</_components.p>{"\n"}<_components.p>{"Below you can see just a part of oc describe output that lists both labels and annotations."}</_components.p>{"\n"}<_components.pre><_components.code className="language-bash">{"oc -n openshift-console describe pod console\n\nName:                 console-85458bcc5b-t7mqs\nNamespace:            openshift-console\nPriority:             2000000000\nPriority Class Name:  system-cluster-critical\nNode:                 crc-gh9wd-master-0/192.168.126.11\nStart Time:           Wed, 20 Nov 2019 08:58:40 -0700\nLabels:               app=console\n                      component=ui\n                      pod-template-hash=85458bcc5b\nAnnotations:          console.openshift.io/console-config-version: 13677\n                      console.openshift.io/image:\n                        quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:2695...8ef\n                      console.openshift.io/infrastructure-config-version: 598\n                      console.openshift.io/oauth-secret-version: 13688\n                      console.openshift.io/oauth-serving-cert-config-version: 10994\n                      console.openshift.io/proxy-config-version: 618\n"}</_components.code></_components.pre>{"\n"}<_components.p>{"I get to use labels quite often, and I hardly ever use annotations. I asked myself what are they and what is their purpose? From the example above it seems that labels are more concise than annotations. It is because they serve different purposes."}</_components.p>{"\n"}<_components.p>{"Labels should be used by end users. If something is meant to be used by a person, put it into a label."}</_components.p>{"\n"}<_components.p>{"Annotations on the other hand are dedicated to be used for technical purposes. You can see in the example above that the Annotation "}<_components.code>{"kubernetes.io/created-by"}</_components.code>{" contains some JSON. Other values are similar to what you can find in the Labels."}</_components.p>{"\n"}<_components.h2>{"Documentation"}</_components.h2>{"\n"}<_components.p>{"The official documentation for OpenShift and Kubernetes serve quite a few examples for both. Just search for annotation or label on the pages below to get a better feeling on how they are used."}</_components.p>{"\n"}<_components.h3>{"Annotations"}</_components.h3>{"\n"}<_components.ul>{"\n"}<_components.li>{"OpenShift Docs: "}<_components.a href="https://docs.openshift.com/container-platform/4.10/networking/routes/route-configuration.html#nw-route-specific-annotations_route-configuration">{"Route-specific annotations"}</_components.a></_components.li>{"\n"}<_components.li>{"OpenShift Docs: "}<_components.a href="https://docs.openshift.com/container-platform/4.10/openshift_images/triggering-updates-on-imagestream-changes.html">{"Triggering updates on imagestream changes"}</_components.a></_components.li>{"\n"}<_components.li>{"OpenShift Docs: "}<_components.a href="https://docs.openshift.com/container-platform/4.10/security/certificates/service-serving-certificate.html#add-service-certificate_service-serving-certificate">{"Securing service traffic using service serving certificates"}</_components.a></_components.li>{"\n"}<_components.li>{"OpenShift Docs: "}<_components.a href="https://docs.openshift.com/container-platform/4.10/nodes/pods/nodes-pods-secrets.html#nodes-pods-secrets-troubleshooting_nodes-pods-secrets">{"Troubleshootin secrets"}</_components.a></_components.li>{"\n"}<_components.li>{"OpenShift Docs: "}<_components.a href="https://docs.openshift.com/container-platform/4.10/networking/multiple_networks/attaching-pod.html">{"Attaching a pod to an additional network"}</_components.a></_components.li>{"\n"}<_components.li>{"Kubernetes Docs: "}<_components.a href="https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/">{"Annotations"}</_components.a>{" – Kubernetes documentation about annotations"}</_components.li>{"\n"}</_components.ul>{"\n"}<_components.h3>{"Labels"}</_components.h3>{"\n"}<_components.ul>{"\n"}<_components.li>{"OpenShift Docs: "}<_components.a href="https://docs.openshift.com/container-platform/4.10/nodes/scheduling/nodes-scheduler-pod-topology-spread-constraints.html">{"Controlling pod placement by using pod topology spread constraints"}</_components.a></_components.li>{"\n"}<_components.li>{"OpenShift Docs: "}<_components.a href="https://docs.openshift.com/container-platform/4.10/applications/deployments/what-deployments-are.html">{"Understanding Deployment and DeploymentConfig objects"}</_components.a></_components.li>{"\n"}<_components.li>{"Kubernetes Docs: "}<_components.a href="https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/">{"Labels and Selectors"}</_components.a>{" – Kubernetes documentation about labels"}</_components.li>{"\n"}</_components.ul>{"\n"}<_components.h2>{"Environment"}</_components.h2>{"\n"}<_components.p>{"The commands were executed using "}<OpenShiftLocal />{" and the following client/server versions of OpenShift."}</_components.p>{"\n"}<KubeBadge client="4.10.9" server="4.10.9" kubernetes="v1.23.5+9ce5071" /></>;
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = Object.assign({}, _provideComponents(), props.components);
  return MDXLayout ? <MDXLayout {...props}><_createMdxContent {...props} /></MDXLayout> : _createMdxContent(props);
}
return {
  default: MDXContent
};
function _missingMdxReference(id, component) {
  throw new Error("Expected " + (component ? "component" : "object") + " `" + id + "` to be defined: you likely forgot to import, pass, or provide it.");
}



When describing pods and other resources, you can see two sets of key value pairs. One is called Labels and the other Annotations.

Below you can see just a part of oc describe output that lists both labels and annotations.

```bash
oc -n openshift-console describe pod console

Name:                 console-85458bcc5b-t7mqs
Namespace:            openshift-console
Priority:             2000000000
Priority Class Name:  system-cluster-critical
Node:                 crc-gh9wd-master-0/192.168.126.11
Start Time:           Wed, 20 Nov 2019 08:58:40 -0700
Labels:               app=console
                      component=ui
                      pod-template-hash=85458bcc5b
Annotations:          console.openshift.io/console-config-version: 13677
                      console.openshift.io/image:
                        quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:2695...8ef
                      console.openshift.io/infrastructure-config-version: 598
                      console.openshift.io/oauth-secret-version: 13688
                      console.openshift.io/oauth-serving-cert-config-version: 10994
                      console.openshift.io/proxy-config-version: 618
```

I get to use labels quite often, and I hardly ever use annotations. I asked myself what are they and what is their purpose? From the example above it seems that labels are more concise than annotations. It is because they serve different purposes.

Labels should be used by end users. If something is meant to be used by a person, put it into a label.

Annotations on the other hand are dedicated to be used for technical purposes. You can see in the example above that the Annotation `kubernetes.io/created-by` contains some JSON. Other values are similar to what you can find in the Labels.

## Documentation

The official documentation for OpenShift and Kubernetes serve quite a few examples for both. Just search for annotation or label on the pages below to get a better feeling on how they are used.

### Annotations

- OpenShift Docs: [Route-specific annotations](https://docs.openshift.com/container-platform/4.10/networking/routes/route-configuration.html#nw-route-specific-annotations_route-configuration)
- OpenShift Docs: [Triggering updates on imagestream changes](https://docs.openshift.com/container-platform/4.10/openshift_images/triggering-updates-on-imagestream-changes.html)
- OpenShift Docs: [Securing service traffic using service serving certificates](https://docs.openshift.com/container-platform/4.10/security/certificates/service-serving-certificate.html#add-service-certificate_service-serving-certificate)
- OpenShift Docs: [Troubleshootin secrets](https://docs.openshift.com/container-platform/4.10/nodes/pods/nodes-pods-secrets.html#nodes-pods-secrets-troubleshooting_nodes-pods-secrets)
- OpenShift Docs: [Attaching a pod to an additional network](https://docs.openshift.com/container-platform/4.10/networking/multiple_networks/attaching-pod.html)
- Kubernetes Docs: [Annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) – Kubernetes documentation about annotations

### Labels

- OpenShift Docs: [Controlling pod placement by using pod topology spread constraints](https://docs.openshift.com/container-platform/4.10/nodes/scheduling/nodes-scheduler-pod-topology-spread-constraints.html)
- OpenShift Docs: [Understanding Deployment and DeploymentConfig objects](https://docs.openshift.com/container-platform/4.10/applications/deployments/what-deployments-are.html)
- Kubernetes Docs: [Labels and Selectors](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) – Kubernetes documentation about labels

## Environment

The commands were executed using <OpenShiftLocal/> and the following client/server versions of OpenShift.

<KubeBadge client='4.10.9' server='4.10.9' kubernetes='v1.23.5+9ce5071'/>


---
index: 3
publishDateTime: '2023-02-19T04:30:00+0200'
isPublished: true
path: /openshift-morsels/03-labels-vs-annotations
group: openshift-morsels
morsel:
  group: basic-knowhow
categories:
- Morsels
- OpenShift
title: 'Labels vs annotations'

---

When describing pods and other resources, you can see two sets of key value pairs. One is called Labels and the other Annotations.

Below you can see just a part of oc describe output that lists both labels and annotations.

```bash
oc -n openshift-console describe pod console

Name:                 console-85458bcc5b-t7mqs
Namespace:            openshift-console
Priority:             2000000000
Priority Class Name:  system-cluster-critical
Node:                 crc-gh9wd-master-0/192.168.126.11
Start Time:           Wed, 20 Nov 2019 08:58:40 -0700
Labels:               app=console
                      component=ui
                      pod-template-hash=85458bcc5b
Annotations:          console.openshift.io/console-config-version: 13677
                      console.openshift.io/image:
                        quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:2695...8ef
                      console.openshift.io/infrastructure-config-version: 598
                      console.openshift.io/oauth-secret-version: 13688
                      console.openshift.io/oauth-serving-cert-config-version: 10994
                      console.openshift.io/proxy-config-version: 618
```

I get to use labels quite often, and I hardly ever use annotations. I asked myself what are they and what is their purpose? From the example above it seems that labels are more concise than annotations. It is because they serve different purposes.

Labels should be used by end users. If something is meant to be used by a person, put it into a label.

Annotations on the other hand are dedicated to be used for technical purposes. You can see in the example above that the Annotation `kubernetes.io/created-by` contains some JSON. Other values are similar to what you can find in the Labels.

## Documentation

The official documentation for OpenShift and Kubernetes serve quite a few examples for both. Just search for annotation or label on the pages below to get a better feeling on how they are used.

### Annotations

- OpenShift Docs: [Route-specific annotations](https://docs.openshift.com/container-platform/4.10/networking/routes/route-configuration.html#nw-route-specific-annotations_route-configuration)
- OpenShift Docs: [Triggering updates on imagestream changes](https://docs.openshift.com/container-platform/4.10/openshift_images/triggering-updates-on-imagestream-changes.html)
- OpenShift Docs: [Securing service traffic using service serving certificates](https://docs.openshift.com/container-platform/4.10/security/certificates/service-serving-certificate.html#add-service-certificate_service-serving-certificate)
- OpenShift Docs: [Troubleshootin secrets](https://docs.openshift.com/container-platform/4.10/nodes/pods/nodes-pods-secrets.html#nodes-pods-secrets-troubleshooting_nodes-pods-secrets)
- OpenShift Docs: [Attaching a pod to an additional network](https://docs.openshift.com/container-platform/4.10/networking/multiple_networks/attaching-pod.html)
- Kubernetes Docs: [Annotations](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) – Kubernetes documentation about annotations

### Labels

- OpenShift Docs: [Controlling pod placement by using pod topology spread constraints](https://docs.openshift.com/container-platform/4.10/nodes/scheduling/nodes-scheduler-pod-topology-spread-constraints.html)
- OpenShift Docs: [Understanding Deployment and DeploymentConfig objects](https://docs.openshift.com/container-platform/4.10/applications/deployments/what-deployments-are.html)
- Kubernetes Docs: [Labels and Selectors](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/) – Kubernetes documentation about labels

## Environment

The commands were executed using <OpenShiftLocal/> and the following client/server versions of OpenShift.

<KubeBadge client='4.10.9' server='4.10.9' kubernetes='v1.23.5+9ce5071'/>


Showing labels of nodes in columns

/*@jsxRuntime automatic @jsxImportSource react*/
const {useMDXComponents: _provideComponents} = arguments[0];
function _createMdxContent(props) {
  const _components = Object.assign({
    p: "p",
    h2: "h2",
    code: "code",
    pre: "pre"
  }, _provideComponents(), props.components), {OpenShiftLocal, KubeBadge} = _components;
  if (!KubeBadge) _missingMdxReference("KubeBadge", true);
  if (!OpenShiftLocal) _missingMdxReference("OpenShiftLocal", true);
  return <><_components.p>{"With more than one node and more advanced setup than in "}<s>{"minishift"}</s>{" "}<s>{"Code Ready Containers"}</s>{" Red Hat OpenShift Local, you can use labels to add metadata to nodes. There are two ways to display later this information."}</_components.p>{"\n"}<_components.h2>{"Showing all labels of a node"}</_components.h2>{"\n"}<_components.p>{"The following command returns all labels of all nodes. Normally the labels are not displayed and the "}<_components.code>{"--show-labels"}</_components.code>{" flag has to be used to show them."}</_components.p>{"\n"}<_components.pre><_components.code className="language-bash">{"$ oc get node\nNAME                 STATUS   ROLES           AGE   VERSION\ncrc-gh9wd-master-0   Ready    master,worker   73d   v1.23.5+9ce5071\n\n\n$ oc get node --show-labels\nNAME                 STATUS   ROLES           AGE   VERSION           LABELS\ncrc-gh9wd-master-0   Ready    master,worker   73d   v1.23.5+9ce5071   beta.kubernetes.io/arch=amd64\n beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=crc-gh9wd-master-0\n kubernetes.io/os=linux,node-role.kubernetes.io/master=,node-role.kubernetes.io/worker=,node.openshift.io/os_id=rhcos\n"}</_components.code></_components.pre>{"\n"}<_components.h2>{"Displaying only selected labels"}</_components.h2>{"\n"}<_components.p>{"As the number of labels and nodes grows, the output becomes unreadable. Usually only some metadata is useful at a time. The displayed labels can be then narrowed just to a few that are helpful."}</_components.p>{"\n"}<_components.p>{"Let's show only architecture and os."}</_components.p>{"\n"}<_components.pre><_components.code className="language-bash">{"$ oc get node -L beta.kubernetes.io/arch,kubernetes.io/os\nNAME                 STATUS   ROLES           AGE   VERSION           ARCH    OS\ncrc-gh9wd-master-0   Ready    master,worker   73d   v1.23.5+9ce5071   amd64   linux\n"}</_components.code></_components.pre>{"\n"}<_components.p>{"I like that the selected labels are shortened and presented in columns. This adds a lot to the readability and makes comparison between nodes a trivial task."}</_components.p>{"\n"}<_components.h2>{"Environment"}</_components.h2>{"\n"}<_components.p>{"The commands were executed using "}<OpenShiftLocal />{" and the following client/server versions of OpenShift."}</_components.p>{"\n"}<KubeBadge client="4.10.9" server="4.10.9" kubernetes="v1.23.5+9ce5071" /></>;
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = Object.assign({}, _provideComponents(), props.components);
  return MDXLayout ? <MDXLayout {...props}><_createMdxContent {...props} /></MDXLayout> : _createMdxContent(props);
}
return {
  default: MDXContent
};
function _missingMdxReference(id, component) {
  throw new Error("Expected " + (component ? "component" : "object") + " `" + id + "` to be defined: you likely forgot to import, pass, or provide it.");
}


With more than one node and more advanced setup than in <s>minishift</s> <s>Code Ready Containers</s> Red Hat OpenShift Local, you can use labels to add metadata to nodes. There are two ways to display later this information.

## Showing all labels of a node

The following command returns all labels of all nodes. Normally the labels are not displayed and the `--show-labels` flag has to be used to show them.

```bash
$ oc get node
NAME                 STATUS   ROLES           AGE   VERSION
crc-gh9wd-master-0   Ready    master,worker   73d   v1.23.5+9ce5071


$ oc get node --show-labels
NAME                 STATUS   ROLES           AGE   VERSION           LABELS
crc-gh9wd-master-0   Ready    master,worker   73d   v1.23.5+9ce5071   beta.kubernetes.io/arch=amd64
 beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=crc-gh9wd-master-0
 kubernetes.io/os=linux,node-role.kubernetes.io/master=,node-role.kubernetes.io/worker=,node.openshift.io/os_id=rhcos
```

## Displaying only selected labels

As the number of labels and nodes grows, the output becomes unreadable. Usually only some metadata is useful at a time. The displayed labels can be then narrowed just to a few that are helpful.

Let's show only architecture and os.

```bash
$ oc get node -L beta.kubernetes.io/arch,kubernetes.io/os
NAME                 STATUS   ROLES           AGE   VERSION           ARCH    OS
crc-gh9wd-master-0   Ready    master,worker   73d   v1.23.5+9ce5071   amd64   linux
```

I like that the selected labels are shortened and presented in columns. This adds a lot to the readability and makes comparison between nodes a trivial task.

## Environment

The commands were executed using <OpenShiftLocal/> and the following client/server versions of OpenShift.

<KubeBadge client='4.10.9' server='4.10.9' kubernetes='v1.23.5+9ce5071'/>



---
index: 2
publishDateTime: '2023-02-18T04:30:00+0200'
isPublished: true
path: /openshift-morsels/02-showing-labels-of-nodes-in-columns
group: openshift-morsels
morsel:
  group: basic-knowhow
categories:
- Morsels
- OpenShift
title: 'Showing labels of nodes in columns'

---
With more than one node and more advanced setup than in <s>minishift</s> <s>Code Ready Containers</s> Red Hat OpenShift Local, you can use labels to add metadata to nodes. There are two ways to display later this information.

## Showing all labels of a node

The following command returns all labels of all nodes. Normally the labels are not displayed and the `--show-labels` flag has to be used to show them.

```bash
$ oc get node
NAME                 STATUS   ROLES           AGE   VERSION
crc-gh9wd-master-0   Ready    master,worker   73d   v1.23.5+9ce5071


$ oc get node --show-labels
NAME                 STATUS   ROLES           AGE   VERSION           LABELS
crc-gh9wd-master-0   Ready    master,worker   73d   v1.23.5+9ce5071   beta.kubernetes.io/arch=amd64
 beta.kubernetes.io/os=linux,kubernetes.io/arch=amd64,kubernetes.io/hostname=crc-gh9wd-master-0
 kubernetes.io/os=linux,node-role.kubernetes.io/master=,node-role.kubernetes.io/worker=,node.openshift.io/os_id=rhcos
```

## Displaying only selected labels

As the number of labels and nodes grows, the output becomes unreadable. Usually only some metadata is useful at a time. The displayed labels can be then narrowed just to a few that are helpful.

Let's show only architecture and os.

```bash
$ oc get node -L beta.kubernetes.io/arch,kubernetes.io/os
NAME                 STATUS   ROLES           AGE   VERSION           ARCH    OS
crc-gh9wd-master-0   Ready    master,worker   73d   v1.23.5+9ce5071   amd64   linux
```

I like that the selected labels are shortened and presented in columns. This adds a lot to the readability and makes comparison between nodes a trivial task.

## Environment

The commands were executed using <OpenShiftLocal/> and the following client/server versions of OpenShift.

<KubeBadge client='4.10.9' server='4.10.9' kubernetes='v1.23.5+9ce5071'/>



Setup oc completion in ONE command

/*@jsxRuntime automatic @jsxImportSource react*/
const {useMDXComponents: _provideComponents} = arguments[0];
function _createMdxContent(props) {
  const _components = Object.assign({
    p: "p",
    h2: "h2",
    pre: "pre",
    code: "code"
  }, _provideComponents(), props.components), {OpenShiftLocal, KubeBadge} = _components;
  if (!KubeBadge) _missingMdxReference("KubeBadge", true);
  if (!OpenShiftLocal) _missingMdxReference("OpenShiftLocal", true);
  return <><_components.p>{"The command and resource completion is built into oc client. At the time of writing this, you can generate it for bash, zsh, fish, powershell."}</_components.p>{"\n"}<_components.h2>{"Generate completion file"}</_components.h2>{"\n"}<_components.p>{"Invoke the following command to generate completion file for your favourite shell:"}</_components.p>{"\n"}<_components.pre><_components.code className="language-shell">{"source <(oc completion bash)\nsource <(oc completion zsh)\noc completion fish | source\n"}</_components.code></_components.pre>{"\n"}<_components.p>{"Or permanently store it in a file and source it from "}<_components.code>{".bashrc"}</_components.code>{".\nMake sure to frequently update it"}</_components.p>{"\n"}<_components.pre><_components.code className="language-bash">{"oc completion bash > oc_completion.sh\n\n# In .bashrc\nsource oc_completion.sh\n"}</_components.code></_components.pre>{"\n"}<_components.p>{"There is also completion for "}<_components.code>{"powershell"}</_components.code>{", but I will leave it to you to check it out."}</_components.p>{"\n"}<_components.h2>{"Documentation"}</_components.h2>{"\n"}<_components.p>{"Check "}<_components.code>{"oc completion --help"}</_components.code>{" to get full documentation about the feature with few more examples.\nIt is constantly evolving, so it is good to revisit from time to time."}</_components.p>{"\n"}<_components.h2>{"Environment"}</_components.h2>{"\n"}<_components.p>{"The commands were executed using "}<OpenShiftLocal />{" and the following client/server versions of OpenShift."}</_components.p>{"\n"}<KubeBadge client="4.10.9" server="4.10.9" kubernetes="v1.23.5+9ce5071" /></>;
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = Object.assign({}, _provideComponents(), props.components);
  return MDXLayout ? <MDXLayout {...props}><_createMdxContent {...props} /></MDXLayout> : _createMdxContent(props);
}
return {
  default: MDXContent
};
function _missingMdxReference(id, component) {
  throw new Error("Expected " + (component ? "component" : "object") + " `" + id + "` to be defined: you likely forgot to import, pass, or provide it.");
}


The command and resource completion is built into oc client. At the time of writing this, you can generate it for bash, zsh, fish, powershell.

## Generate completion file

Invoke the following command to generate completion file for your favourite shell:

```shell
source <(oc completion bash)
source <(oc completion zsh)
oc completion fish | source
```

Or permanently store it in a file and source it from `.bashrc`.
Make sure to frequently update it

```bash
oc completion bash > oc_completion.sh

# In .bashrc
source oc_completion.sh
```

There is also completion for `powershell`, but I will leave it to you to check it out.

## Documentation
Check `oc completion --help` to get full documentation about the feature with few more examples.
It is constantly evolving, so it is good to revisit from time to time.

## Environment

The commands were executed using <OpenShiftLocal/> and the following client/server versions of OpenShift.

<KubeBadge client='4.10.9' server='4.10.9' kubernetes='v1.23.5+9ce5071'/>



---
index: 1
publishDateTime: '2023-02-17T04:30:00+0200'
isPublished: true
path: /openshift-morsels/01-setup-kubectl-completion-in-one-command
group: openshift-morsels
morsel:
  group: basic-knowhow
categories:
- Morsels
- OpenShift
title: 'Setup oc completion in ONE command'

---
The command and resource completion is built into oc client. At the time of writing this, you can generate it for bash, zsh, fish, powershell.

## Generate completion file

Invoke the following command to generate completion file for your favourite shell:

```shell
source <(oc completion bash)
source <(oc completion zsh)
oc completion fish | source
```

Or permanently store it in a file and source it from `.bashrc`.
Make sure to frequently update it

```bash
oc completion bash > oc_completion.sh

# In .bashrc
source oc_completion.sh
```

There is also completion for `powershell`, but I will leave it to you to check it out.

## Documentation
Check `oc completion --help` to get full documentation about the feature with few more examples.
It is constantly evolving, so it is good to revisit from time to time.

## Environment

The commands were executed using <OpenShiftLocal/> and the following client/server versions of OpenShift.

<KubeBadge client='4.10.9' server='4.10.9' kubernetes='v1.23.5+9ce5071'/>



Setup kubectl completion in ONE command

/*@jsxRuntime automatic @jsxImportSource react*/
const {useMDXComponents: _provideComponents} = arguments[0];
function _createMdxContent(props) {
  const _components = Object.assign({
    p: "p",
    h2: "h2",
    pre: "pre",
    code: "code"
  }, _provideComponents(), props.components), {KubeBadge} = _components;
  if (!KubeBadge) _missingMdxReference("KubeBadge", true);
  return <><_components.p>{"The command and resource completion is built into kubectl. You can generate it for bash and zsh."}</_components.p>{"\n"}<_components.h2>{"Generate completion file"}</_components.h2>{"\n"}<_components.p>{"Invoke the following command to generate completion file:"}</_components.p>{"\n"}<_components.pre><_components.code className="language-bash">{"source <(kubectl completion bash)\nsource <(kubectl completion zsh)\n"}</_components.code></_components.pre>{"\n"}<_components.p>{"Or permanently store it in a file and source it from "}<_components.code>{".bashrc"}</_components.code>{".\nMake sure to update it whenever you update "}<_components.code>{"kubectl"}</_components.code>{" version"}</_components.p>{"\n"}<_components.pre><_components.code className="language-bash">{"kubectl completion bash > kubectl_completion.sh\n\n# In .bashrc\nsource kubectl_completion.sh\n"}</_components.code></_components.pre>{"\n"}<_components.p>{"There is also completion for "}<_components.code>{"powershell"}</_components.code>{", but I will leave it to you to check it out."}</_components.p>{"\n"}<_components.h2>{"Documentation"}</_components.h2>{"\n"}<_components.p>{"Check "}<_components.code>{"oc completion --help"}</_components.code>{" to get full documentation about the feature with few more examples.\nIt is constantly evolving, so it is good to revisit from time to time."}</_components.p>{"\n"}<_components.h2>{"Environment"}</_components.h2>{"\n"}<_components.p>{"The commands were executed using kubectl"}</_components.p>{"\n"}<KubeBadge kubernetes="v1.25.3" /></>;
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = Object.assign({}, _provideComponents(), props.components);
  return MDXLayout ? <MDXLayout {...props}><_createMdxContent {...props} /></MDXLayout> : _createMdxContent(props);
}
return {
  default: MDXContent
};
function _missingMdxReference(id, component) {
  throw new Error("Expected " + (component ? "component" : "object") + " `" + id + "` to be defined: you likely forgot to import, pass, or provide it.");
}


The command and resource completion is built into kubectl. You can generate it for bash and zsh.

## Generate completion file

Invoke the following command to generate completion file:

```bash
source <(kubectl completion bash)
source <(kubectl completion zsh)
```

Or permanently store it in a file and source it from `.bashrc`.
Make sure to update it whenever you update `kubectl` version

```bash
kubectl completion bash > kubectl_completion.sh

# In .bashrc
source kubectl_completion.sh
```

There is also completion for `powershell`, but I will leave it to you to check it out.

## Documentation
Check `oc completion --help` to get full documentation about the feature with few more examples.
It is constantly evolving, so it is good to revisit from time to time.

## Environment

The commands were executed using kubectl

<KubeBadge kubernetes='v1.25.3'/>

---
index: 1
publishDateTime: '2023-02-15T04:30:00+0200'
isPublished: true
path: /kubernetes-morsels/01-setup-kubectl-completion-in-one-command
group: kubernetes-morsels
morsel:
  group: basic-knowhow
categories:
- morsels
- kubernetes
- kubernetes morsels
title: 'Setup kubectl completion in ONE command'
---
The command and resource completion is built into kubectl. You can generate it for bash and zsh.

## Generate completion file

Invoke the following command to generate completion file:

```bash
source <(kubectl completion bash)
source <(kubectl completion zsh)
```

Or permanently store it in a file and source it from `.bashrc`.
Make sure to update it whenever you update `kubectl` version

```bash
kubectl completion bash > kubectl_completion.sh

# In .bashrc
source kubectl_completion.sh
```

There is also completion for `powershell`, but I will leave it to you to check it out.

## Documentation
Check `oc completion --help` to get full documentation about the feature with few more examples.
It is constantly evolving, so it is good to revisit from time to time.

## Environment

The commands were executed using kubectl

<KubeBadge kubernetes='v1.25.3'/>

Install SSH key from github or gitlab

/*@jsxRuntime automatic @jsxImportSource react*/
const {useMDXComponents: _provideComponents} = arguments[0];
function _createMdxContent(props) {
  const _components = Object.assign({
    p: "p",
    a: "a",
    h2: "h2",
    pre: "pre",
    code: "code"
  }, _provideComponents(), props.components);
  return <><_components.p>{"Well, that was a surprise. When installing "}<_components.a href="https://ubuntu.com/download/server">{"Ubuntu Server"}</_components.a>{" for the first time, the installer asked for github user name to automatically install SSH key in the VM."}</_components.p>{"\n"}<_components.p>{"I found this to be useful for all the VMs I create. It is a simple way to add SSH keys to new VM."}</_components.p>{"\n"}<_components.h2>{"Install SSH key from github"}</_components.h2>{"\n"}<_components.p>{"Of course the assumption is that you already have an SSH key "}<_components.a href="https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account">{"added to github"}</_components.a>{" or "}<_components.a href="https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account">{"gitlab"}</_components.a></_components.p>{"\n"}<_components.pre><_components.code className="language-bash">{"mkdir ~/.ssh\nchmod 700 ~/.ssh\ncd ~/.ssh\n# for github\ncurl https://github.com/<user-name>.keys --output authorized_keys\n# or for gitlab\ncurl https://gitlab.com/<user-name>.keys --output authorized_keys\nchmod 600 authorized_keys\n"}</_components.code></_components.pre>{"\n"}<_components.p>{"Just a reminder, create safe SSH keys and protect them with secure passwords. And always protect your accounts with two factor authentication (2FA)."}</_components.p></>;
}
function MDXContent(props = {}) {
  const {wrapper: MDXLayout} = Object.assign({}, _provideComponents(), props.components);
  return MDXLayout ? <MDXLayout {...props}><_createMdxContent {...props} /></MDXLayout> : _createMdxContent(props);
}
return {
  default: MDXContent
};


Well, that was a surprise. When installing [Ubuntu Server](https://ubuntu.com/download/server) for the first time, the installer asked for github user name to automatically install SSH key in the VM.

I found this to be useful for all the VMs I create. It is a simple way to add SSH keys to new VM.  

## Install SSH key from github

Of course the assumption is that you already have an SSH key [added to github](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account) or [gitlab](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account)

```bash
mkdir ~/.ssh
chmod 700 ~/.ssh
cd ~/.ssh
# for github
curl https://github.com/<user-name>.keys --output authorized_keys
# or for gitlab
curl https://gitlab.com/<user-name>.keys --output authorized_keys
chmod 600 authorized_keys
```

Just a reminder, create safe SSH keys and protect them with secure passwords. And always protect your accounts with two factor authentication (2FA).




---
index: 1
publishDateTime: '2017-02-08T04:30:00+0200'
isPublished: true
path: /linux-morsels/01-install-SSH-key-from-github-or-gitlab
group: linux-morsels
morsel:
  group: basic-knowhow
categories:
- Morsels
- Linux
title: 'Install SSH key from github or gitlab'
---
Well, that was a surprise. When installing [Ubuntu Server](https://ubuntu.com/download/server) for the first time, the installer asked for github user name to automatically install SSH key in the VM.

I found this to be useful for all the VMs I create. It is a simple way to add SSH keys to new VM.  

## Install SSH key from github

Of course the assumption is that you already have an SSH key [added to github](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account) or [gitlab](https://docs.github.com/en/authentication/connecting-to-github-with-ssh/adding-a-new-ssh-key-to-your-github-account)

```bash
mkdir ~/.ssh
chmod 700 ~/.ssh
cd ~/.ssh
# for github
curl https://github.com/<user-name>.keys --output authorized_keys
# or for gitlab
curl https://gitlab.com/<user-name>.keys --output authorized_keys
chmod 600 authorized_keys
```

Just a reminder, create safe SSH keys and protect them with secure passwords. And always protect your accounts with two factor authentication (2FA).




Latest posts