container.training/docs/kubectlget.md

First contact with kubectl

• kubectl is (almost) the only tool we'll need to talk to Kubernetes

• It is a rich CLI tool around the Kubernetes API

  (Everything you can do with kubectl, you can do directly with the API)

• On our machines, there is a ~/.kube/config file with:

  • the Kubernetes API address

  • the path to our TLS certificates used to authenticate

• You can also use the --kubeconfig flag to pass a config file

• Or directly --server, --user, etc.

• kubectl can be pronounced "Cube C T L", "Cube cuttle", "Cube cuddle"...

---

kubectl get

• Let's look at our Node resources with kubectl get!

.exercise[

• Look at the composition of our cluster:

  kubectl get node
  

• These commands are equivalent:

  kubectl get no
  kubectl get node
  kubectl get nodes
  

]

---

From human-readable to machine-readable output

• kubectl get can output JSON, YAML, or be directly formatted

.exercise[

• Give us more info about them nodes:

  kubectl get nodes -o wide
  

• Let's have some YAML:

  kubectl get no -o yaml
  

  See that kind: List at the end? It's the type of our result!

]

---

(Ab)using kubectl and jq

• It's super easy to build custom reports

.exercise[

• Show the capacity of all our nodes as a stream of JSON objects:

    kubectl get nodes -o json | 
            jq ".items[] | {name:.metadata.name} + .status.capacity"
  

]

---

What's available?

• kubectl has pretty good introspection facilities

• We can list all available resource types by running kubectl get

• We can view details about a resource with:

  kubectl describe type/name
  kubectl describe type name
  

• We can view the definition for a resource type with:

  kubectl explain type
  

Each time, type can be singular, plural, or abbreviated type name.

---

Services

• A service is a stable endpoint to connect to "something"

  (In the initial proposal, they were called "portals")

.exercise[

• List the services on our cluster with one of these commands:

  kubectl get services
  kubectl get svc
  

]

--

There is already one service on our cluster: the Kubernetes API itself.

---

ClusterIP services

• A ClusterIP service is internal, available from the cluster only

• This is useful for introspection from within containers

.exercise[

• Try to connect to the API:

  curl -k https://`10.96.0.1`
  

  • -k is used to skip certificate verification
  • Make sure to replace 10.96.0.1 with the CLUSTER-IP shown earlier

]

--

The error that we see is expected: the Kubernetes API requires authentication.

---

Listing running containers

• Containers are manipulated through pods

• A pod is a group of containers:

• running together (on the same node)

• sharing resources (RAM, CPU; but also network, volumes)

.exercise[

• List pods on our cluster:

  kubectl get pods
  

]

--

These are not the pods you're looking for. But where are they?!?

---

Namespaces

• Namespaces allow to segregate resources

.exercise[

• List the namespaces on our cluster with one of these commands:

  kubectl get namespaces
  kubectl get namespace
  kubectl get ns
  

]

--

You know what ... This kube-system thing looks suspicious.

---

Accessing namespaces

• By default, kubectl uses the default namespace

• We can switch to a different namespace with the -n option

.exercise[

• List the pods in the kube-system namespace:

  kubectl -n kube-system get pods
  

]

--

Ding ding ding ding ding!

---

What are all these pods?

• etcd is our etcd server

• kube-apiserver is the API server

• kube-controller-manager and kube-scheduler are other master components

• kube-dns is an additional component (not mandatory but super useful, so it's there)

• kube-proxy is the (per-node) component managing port mappings and such

• weave is the (per-node) component managing the network overlay

• the READY column indicates the number of containers in each pod

• the pods with a name ending with -ip-172-31-XX-YY are the master components
  (they have been specifically "pinned" to the master node)