Moving to Declarative YAML

kubectl apply

  • Remember the three management approaches?

  • Let’s skip to full Declarative objects

  • kubectl apply -f filename.yml

  • Why skip kubectl create, kubectl replace, kubectl edit?

  • What I recommend is not equal to all thats possible

Using kubectl apply

  • Create/update resources in a file

    • kubectl apply -f myfile.yaml

  • Create/update a whole directory of yaml

    • kubectl apply -f myyaml/

  • Create/update from a URL

    • kubectl apply -f https://bret.run/pod.yml

  • Be careful, lets look at it first (browser or curl)

    • curl -L https://bret.run/pod

Kubernetes Configuration YAML

  • Kubernetes config file (YAML or JSON)

  • Each file contains one or more manifests

  • Each manifest describes an API object (deployment, job, secret)

  • Each manifest needs four parts (root key:values in the file)

    • apiVersion

    • kind

    • metadata

    • spec

Building your YAML Files

  • kind: We can get a list of resources the cluster supports

    • kubectl api-resources

  • Notice some resoucres have multiple APIs (old vs new)

  • apiVersion We can get the API versions the cluster supports

    • kubectl api-versions

  • metadata: only name is required

  • spec: Where all the action is at!

Buildng your YAML Spec

  • We can get all the keys each kind supports

    • kubectl explain services –recursive

    • kubectl explain services.spec

  • We can walk through the spec this way

    • kubectl explain services.spec.type

  • spec: can have sub spect: of other resources

    • kubectl explain deployment.spec.template.spec.volumes.nfs.server

  • We can also use docs

    • kubernetes.io/docs/reference/#api-reference

Dry Runs and Diffs

  • dry-run a create (client side only)

    • kubectl apply -f app.yml –dry-run

  • dry-run a create/update on server

    • kubectl apply -f app.yml –server-dry-run

  • see a diff visually

    • kubectl diff -f app.yml

Labels and Annotations

  • Labels goes under metadata: in your YAML

  • Simple list of key: value for identifying your resource later by selecting, grouping, or filtering for it

  • Common examples include tier: frontend, app: api, env: prod, customer: acme.co

  • Not meant to hold complex, large, or non-identifying info, which is what annotations are for

  • filter a get command

    • kubectl get pods -l app=nginx

  • apply only matching labels

    • kubectl apply -f myfile.yaml -l app=nginx

Label Selectors

  • The “glue” telling Services and Deployments which pods are theirs

  • Many resources use Label Selectors to “link” resource dependancies

  • You’ll see these match up in the Service and Deployment YAML

  • Use Labels and Selectors to control which pods go to which nodes

  • Taints and Tolerations also control node placement