DEV Community: Peter Jausovec

Kubernetes CLI (kubectl) tips you didn't know about

Peter Jausovec — Tue, 28 Jun 2022 16:45:55 +0000

AhmetB started an excellent thread yesterday where he asked people to share a Kubernetes CLI (kubectl) tip that they think a lot of users don't know about.

// Detect dark theme var iframe = document.getElementById('tweet-1523741824141041664-800'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1523741824141041664&theme=dark" }

There are so many excellent tips I decided to collect the most interesting ones in a single post. The first thing that I typically do when I am on a new machine is to set the alias for kubectl:

alias k=kubectl

If you're working with Kubernetes, you'll be typing kubectl a lot, so why not make it shorter.

Enjoy the tips below and let us know if you have any other tips you want to share. Here are all the tips in no particular order.

1. Set up load-based horizontal pod autoscaling on your Kubernetes resources

By @pixie_run

kubectl autoscale deployment foo --min=2 --max=10

2. Create a new job from a cronjob

By @mauilion

kubectl create job --from=cronjob/<name of cronjob> <name of this run>

3. Enumerate permissions for a given service account

By @mauilion

kubectl -n <namespace> auth can-i --list --as system:serviceaccount:<namespace>:<service account name>

4. Annotate resources

By @hikvar

# To add annotation
kubectl annotate <resource-type>/<resource-name> foo=bar
# To remove annotation
kubectl annotate <resource-type>/<resource-name> foo-

5. Get a list of endpoints across all namespaces

By ivnrcki

kubectl get ep -A

6. Get a list of events sorted by lastTimestamp

By RewssPozzi

kubectl get events --sort-by=".lastTimestamp"

7. Watch all warnings across the namespaces

By @LachlanEvenson and @jpetazzo

kubectl get events -w --field-selector=type=Warning -A

8. Add the `EVENT` column to the list of watched pods

By Jérôme Petazzoni

kubectl get pods --watch --output-watch-events

9. Get raw JSON for the various APIs

By cheddarmint and @mauilion

kubectl get --raw /apis/apps/v1

# Get metrics
kubectl get --raw /metrics

10. Wait for specific pods to be ready

By @csanchez

kubectl wait --for=condition=ready pod -l foo=bar

11. Explain the various resources

By @pratikbin

kubectl explain pod.spec

12. Get all resources that match a selector

By @jpetazzo

kubectl get deployments,replicasets,pods,services --selector=hello=yourecute

13. Forward a port from a service to a local port

By @victortrac

kubectl port-forward svc/<service-name> <local-port>:<remote-port>

14. List the environment variables for a resource

By @oldmanuk

kubectl set env <resource>/<resource-name> --list

15. Get a list of pods and the node they run on

By @damnlamb

kubectl get po -o=custom-columns=NODE:.spec.nodeName,NAME:.metadata.name

16. Create a starter YAML manifest for deployment (also works for other resources)

By @ll_Cool__Josh

kubectl create deploy nginx-deployment --image=nginx --dry-run=client -o yaml

17. Get a list of pods sorted by memory usage

By @NehmiHungry

kubectl top pods -A --sort-by='memory'

18. Get a list of pods that have a specific label value set

By @shrayk

kubectl get pods -l 'app in (foo,bar)'

19. Get the pod logs before the last restart

By @_elvir_kuric_

kubectl logs <pod-name> --previous

20. Copy a file from a pod to a local file

By @oshi1136

kubectl cp <namespace>/<pod>:<file_path> <local_file_path>

21. Delete a pod immediately

By @Rodrigo_Loza_L

kubectl delete pod <pod-name> --now

22. Show the logs from pods with specific labels

By @oldmanuk

kubectl logs -l app=xyz

23. Get more information about the resources (aka wide-view)

By @hrvojekov

kubectl get <resource> -o wide

24. Output and apply the patch

By @gipszlyakab

# Edit a resource and get the patch
kubectl edit <resource>/<name> --output-patch

# Use the output from the command above to apply the patch
kubectl patch --patch=<output_from_previous_command>

How to configure Firebase emulators with Next.js?

Peter Jausovec — Fri, 04 Mar 2022 00:00:00 +0000

I've been working with Next.js and Firebase and using the Firebase emulators for local development. Firebase has a generous free tier, so unless you're doing something wrong or your project is growing, you probably won't hit those limits any time soon. Regardless, setting up the emulators and running against them instead of a deployed Firebase project simplifies development and testing. It also allows you to iterate faster (i.e., you don't have to re-deploy the functions N times a day), you can quickly run tests to make sure you don't break any basic functionality (or even security rules), and you can quickly seed the database with different documents.

My project is in a single repo that contains the functions (backend folder) and the Next.js frontend (web folder). Here's a simplified version of the repo structure:

.
├── backend
│   └── functions
└── web
    ├── node_modules
    ├── public
    └── src

The backend folder contains the functions, and it's where you initialize the Firebase project (i.e., run the firebase init com). The web folder contains the Next.js frontend.

Launching the Firebase emulators

Before you launch the emulators, you'll have to configure (and download) them first. The easiest way to do that is to run firebase init, go through the prompts and select the emulators you want to use.

You should end up with something similar in the firebase.json file:

...
  "emulators": {
    "auth": {
      "port": 9099
    },
    "functions": {
      "port": 5001
    },
    "firestore": {
      "port": 8080
    },
    "database": {
      "port": 9000
    },
    "hosting": {
      "port": 5000
    },
    "pubsub": {
      "port": 8085
    },
    "storage": {
      "port": 9199
    },
    "ui": {
      "enabled": true
    }
  }

Launching the emulators is pretty straightforward - I typically launch them in a separate terminal window with firebase emualtors:start command.

$ firebase emulators:start
i  emulators: Starting emulators: auth, functions, firestore, database, hosting, pubsub
, storage
...
┌─────────────────────────────────────────────────────────────┐
│ ✔  All emulators ready! It is now safe to connect your app. │
│ i  View Emulator UI at http://localhost:4000                │
└─────────────────────────────────────────────────────────────┘

┌────────────────┬──────────────────────────────────┬─────────────────────────────────┐
│ Emulator       │ Host:Port                        │ View in Emulator UI             │
├────────────────┼──────────────────────────────────┼─────────────────────────────────┤
│ Authentication │ localhost:9099                   │ http://localhost:4000/auth      │
├────────────────┼──────────────────────────────────┼─────────────────────────────────┤
│ Functions      │ localhost:5001                   │ http://localhost:4000/functions │
├────────────────┼──────────────────────────────────┼─────────────────────────────────┤
│ Firestore      │ localhost:8080                   │ http://localhost:4000/firestore │
├────────────────┼──────────────────────────────────┼─────────────────────────────────┤
│ Database       │ localhost:9000                   │ http://localhost:4000/database  │
├────────────────┼──────────────────────────────────┼─────────────────────────────────┤
│ Hosting        │ Failed to initialize (see above) │                                 │
├────────────────┼──────────────────────────────────┼─────────────────────────────────┤
│ Pub/Sub        │ localhost:8085                   │ n/a                             │
├────────────────┼──────────────────────────────────┼─────────────────────────────────┤
│ Storage        │ localhost:9199                   │ http://localhost:4000/storage   │
└────────────────┴──────────────────────────────────┴─────────────────────────────────┘
  Emulator Hub running at localhost:4400
  Other reserved ports: 4500

If all goes well, the emulators will be running, and you can open the emulator UI on localhost:4000 - it should look similar to the figure below.

Firebase Emulator Suite

You can click the "Go to emulator" links to get to the specific emulator UI. The UI looks similar to the actual Firebase UI. For example, in the Firestore emulator, you can create and delete collections and documents, in the Authentication emulator, you can add users, and so on.

We can now connect to them from the front-end application with the emulators running.

Connecting to the emulators from Next.js

Whether you're using Next.js or not, the way you connect to the local emulators is the same. The only difference is whether you're connecting from the frontend (using the firebase library) or the backend (using the firebase-admin library).

Since each service in the Firebase suite has its emulator, you have to connect to them individually. This flexibility is great because theoretically, you could use the "production" auth service and connect to the Firestore or Storage emulator or any other combination of emulator and non-emulator service. However, in most cases, if you're developing locally, you'd connect to all service emulators and not mix them up.

With the modular Firebase library, each one of the modules exposes a connectXYZEmulator function. I am also using the reactfire library that implements providers for each service - that's where I decide whether to connect to the emulator or not.

For example, in my FirebaseAuthProvider function, I do something like this:

import {
  useFirebaseApp,
} from 'reactfire';

import {
  connectAuthEmulator,
  getAuth
} from 'firebase/auth';

function shouldConnectAuthEmulator(): boolean {
  // You could do any logic here to decide whether to connect to the emulator or not
  return process.env.NODE_ENV === 'development');
}

function getAuthEmulatorHost(): string {
  // You'd read this from config/environment variable/etc.
  return 'localhost:9099';
}

export const FirebaseAuthProvider = ({ children }) => {
  const app = useFirebaseApp();
  const auth = getAuth(app);

  if (shouldConnectAuthEmulator()) {
    connectAuthEmulator(auth, getAuthEmulatorHost());
  }
  ...
}

The connect function takes the Firebase service, host, and any specific options to the emulator. And that's all! That one call to connectAuthEmulator will connect to the local Authentication emulator. Similarly, you can connect to other emulators.

Connecting from the backend using `firebase-admin`

The firebase-admin library is meant to be used for accessing Firebase from server environments (as opposed to frontend and client browsers).

In the front-end scenario, exposing the API key, app ID, auth domain, and other configuration values is not an issue. In a typical scenario, you'd register/login the user first and then use their token to allow/deny different types of access to the Firebase.

However, using the firebase-admin library in the backend scenario, you have to provide a private key to connect to the Firebase. It would be best never to share the private key as it gives administrative access to the Firebase. Hence, you'd only use the Firebase admin library from trusted environments and never from the client (frontend).

Read more on how to set up Firebase on a server here

When using the admin version of the Firebase library, you won't find the connectXYZEmulator functions. Instead, you'll have to set environment variables that point to the emulators.

If we continue with the auth example above, you connect to the emulator by setting the FIREBASE_AUTH_EMULATOR_HOST environment variable to localhost:9099. Similarly, you'd set FIREBASE_STORAGE_EMULATOR_HOST for Storage and FIREBASE_FUNCTIONS_EMULATOR_HOST for Functions so on. You can check more details in the documentation here.

Monitoring containers with cAdvisor

Peter Jausovec — Wed, 25 Aug 2021 20:43:25 +0000

Monitoring with cAdvisor allows you to gather information about individual Docker containers running on your host - be it a virtual machine, Kubernetes cluster, or any other host capable of running containers.

cAdvisor (short for "Container Advisor") is a daemon that collects the data about the resource usage and performance of your containers.

In addition to container usage metrics, cAdvisor can also collect metrics from your applications. If your applications are already emitting metrics, you can configure cAdviser to scrape the endpoint and include which metrics you want to extract.

cAdvisor also features a built-in UI, and it also allows you to export the collected data to different storage driver plugins.

For example, you can export the collected data to:

The easiest way to get started and see the data that gets collected is to run the cAdvisor Docker image locally:

sudo docker run \
  --volume=/:/rootfs:ro \
  --volume=/var/run:/var/run:ro \
  --volume=/sys:/sys:ro \
  --volume=/var/lib/docker/:/var/lib/docker:ro \
  --volume=/dev/disk/:/dev/disk:ro \
  --publish=8080:8080 \
  --detach=true \
  --name=cadvisor \
  --privileged \
  --device=/dev/kmsg \
  gcr.io/cadvisor/cadvisor:v0.37.5

The latest version of cAdvisor at the time of writing this was v0.37.5. Make sure you're always using the latest bits.

In case you're wondering about all those volumes... These are the folders you need to mount inside the cAdvisor image so that the cAdvisor can analyze all the data from them.

Once the cAdvisor is running, it will collect data about all containers running on the same host. Note that there are options you can set to limit which containers get monitored.

Running cAdvisor in Kubernetes

cAdvisor is integrated with the kubelet binary, and it exposes the metrics on /metrics/cadvisor endpoint.

Therefore we don't need to install cAdvisor on the Kubernetes cluster explicitly.

Here's an example of how we can use kubectl to retrieve the cluster node metrics and Pod metrics:

$ kubectl get --raw /apis/metrics.k8s.io/v1beta1/nodes/[node-name]
{
  "kind": "NodeMetrics",
  "apiVersion": "metrics.k8s.io/v1beta1",
  "metadata": {
    "name": "[node-name]",
    "selfLink": "/apis/metrics.k8s.io/v1beta1/nodes/[node-name]]",
    "creationTimestamp": "2021-08-26T22:12:26Z"
  },
  "timestamp": "2021-08-26T22:11:53Z",
  "window": "30s",
  "usage": {
    "cpu": "39840075n",
    "memory": "487200Ki"
  }
}

Similarly, we can use the following URL /apis/metrics.k8s.io/v1beta1/namespaces/<NAMESPACE>/pods/<POD_NAME> to get the metrics about a specific pod.

Let's create an httpbin deployment:

kubectl apply -f https://raw.githubusercontent.com/istio/istio/master/samples/httpbin/httpbin.yaml

To retrieve the metrics from the httpbin pod, run the command below (make sure you replace the pod name with the name of your pod running in your cluster):

$ kubectl get --raw /apis/metrics.k8s.io/v1beta1/namespaces/default/pods/httpbin-74fb669cc6-xs74p
{
  "kind": "PodMetrics",
  "apiVersion": "metrics.k8s.io/v1beta1",
  "metadata": {
    "name": "httpbin-74fb669cc6-xs74p",
    "namespace": "default",
    "selfLink": "/apis/metrics.k8s.io/v1beta1/namespaces/default/pods/httpbin-74fb669cc6-xs74p",
    "creationTimestamp": "2021-08-26T22:15:40Z"
  },
  "timestamp": "2021-08-26T22:15:16Z",
  "window": "30s",
  "containers": [
    {
      "name": "httpbin",
      "usage": {
        "cpu": "316267n",
        "memory": "38496Ki"
      }
    }
  ]
}

Connecting cAdvisor to Prometheus and Grafana

By default, cAdvisor exposes the Prometheus metrics on the /metrics endpoint.

# HELP cadvisor_version_info A metric with a constant '1' value labeled by kernel version, OS version, docker version, cadvisor version & cadvisor revision.
# TYPE cadvisor_version_info gauge
cadvisor_version_info{cadvisorRevision="de117632",cadvisorVersion="v0.39.0",dockerVersion="20.10.3",kernelVersion="5.4.104+",osVersion="Alpine Linux v3.12"} 1
# HELP container_blkio_device_usage_total Blkio Device bytes usage
# TYPE container_blkio_device_usage_total counter
container_blkio_device_usage_total{container_env_ARG1="",container_env_ARG2="",container_env_CADVISOR_HEALTHCHECK_URL="",container_env_DEFAULT_HTTP_BACKEND_PORT="",container_env_DEFAULT_HTTP_BACKEND_PORT_80_TCP="",container_env_DEFAULT_HTTP_BACKEND_PORT_80_TCP_ADDR="",container_env_DEFAULT_HTTP_BACKEND_PORT_80_TCP_PORT="",container_env_DEFAULT_HTTP_BACKEND_PORT_80_TCP_PROTO="",
...

Because metrics are already in Prometheus format and cAdvisor exports them automatically on a well-known endpoint, we don't need to change the existing cAdvisor deployment. Instead, we can install and configure Prometheus to scrape the metrics from the /metrics endpoint.

Installing Prometheus on Kubernetes

I'll use Prometheus Operator to install Prometheus on Kubernetes. We'll install the complete monitoring bundle, including Prometheus, Grafana, and Alert manager.

Start by cloning the kube-prometheus repository:

git clone https://github.com/prometheus-operator/kube-prometheus.git

Then, go to the kube-prometheus folder and deploy the CRDs first:

kubectl apply -f manifests/setup

Wait for a bit for the CRDs to be applied and then create the deployments:

kubectl apply -f manifests/

Once you've deployed everything (you can run kubectl get pod -A to check all pods are up and running), you can open the Prometheus UI:

kubectl port-forward svc/prometheus-k8s 9090 -n monitoring

If you open http://localhost:9090, you can now query for any metrics collected by the cAdvisor - e.g., metrics starting with container_* as shown in the figure below.

Grafana dashboards

Grafana gets installed as part of the kube-prometheus operator. We can open the Grafana UI by port-forwarding to port 3000:

kubectl port-forward svc/grafana 5000:3000 -n monitoring

If you open Grafana on http://localhost:5000 you'll notice there's already a set of pre-created dashboards that came with the kube-prometheus operator.

The dashboards show you the information about Kubernetes resources - memory usage, CPU usage, quotas, and so on. These metrics are coming from the node-exporter component.

The node-exporter exports the hardware and OS metrics to Prometheus while cAdvisor collects the metrics about containers.

To get the cAdvisor metrics pulled into Grafana, we'll install the Kubernetes cluster monitoring (via Prometheus) dashboard from Grafana.

Installing a dashboard is straightforward.

In Grafana, go to the "+" button on the sidebar.
Click Import.

Paste the dashboard ID (315 in our case) to the ID text field
Click the Load button.
From the Prometheus drop-down list, select "prometheus".
Click the Import button.

When Grafana imports the dashboard, it will automatically open it. The dashboard features high-level metrics about the total CPU and memory usage and detailed metrics about each specific container.

What's next?

As the next step, you should familiarize yourself with the graphs and data displayed in Grafana and learn how to read them. Find which metrics and dashboards are valuable to you and your system.

Once you've decided that, you might want to set up the alerting. The Prometheus operator includes the Alert manager. You can use the alert manager and configure it to send alerts when specific metrics are not within the defined thresholds. For example, you could configure the system to send a notification to PagerDuty whenever the cluster memory or CPU usage is above a certain threshold.

Resources

🎥 Kubernetes Services, Ingress, Jobs and CronJobs

Peter Jausovec — Thu, 17 Jun 2021 03:37:22 +0000

How can you access workloads inside the Kubernetes cluster? Should you use a NodePort or LoadBalancer service type? How about if you want to expose multiple applications through a single load balancer? In this session, you'll learn how to do all that. We'll deploy an Ambassador ingress controller and show how to expose multiple applications through the load balancer. Finally, we'll look into Jobs and CronJobs and show how to use them to run tasks on schedule.

What's covered in the video?

00:00 - Introduction
01:00 - Agenda
02:54 - Kubernetes Services
10:24 - Talking to Pods using services (demo/lab)
23:37 - Service types
24:45 - ClusterIP service type
25:56 - NodePort service type
28:00 - LoadBalancer service type
29:00 - ExternalName service type
30:03 - Service types (demo/lab)
40:40 - Ingress introduction (exposing multiple services)
50:50 - Ingress (demo)
54:33 - Deploying Ambassador ingress controller (demo)
01:00:50 - Single service ingress (demo)
01:02:59 - Path-based routing with Ingress (demo)
01:08:13 - Using a hostname instead of an IP address (demo)
01:15:31 - Name-based ingress(multiple hosts) (demo)
01:19:00 - Kubernetes Jobs
01:26:39 - Kubernetes CronJobs
01:32:40 - Jobs and CronJobs (demo)

You can find all the information on how to join the next live Kubernetes session at live.startkubernetes.com!

Start Kubernetes Live Stream: Pods, ReplicaSets, and Deployments

Peter Jausovec — Mon, 31 May 2021 22:58:17 +0000

I did my first YouTube live stream this weekend. I took a couple of days to edit the video - not because there was a lot of edits, but because it takes 8+ hours for YouTube to process the changes :)

In the first video I am talking about Kubernetes Pods, ReplicaSets, and Deployments.

Here are the topics covered in the video:

00:00 Introduction
05:22 Container orchestration
08:32 Kubernetes introduction
10:21 Kubernetes architecture
18:37 Kubernetes resources
22:40 Anatomy of a resource
26:56 Labels
27:27 Selectors
29:19 Annotations
31:46 Namespaces
34:53 Pods
47:17 Creating a cluster in GCP
01:02:04 Pods Demo
01:09:40 ReplicaSet
01:16:40 ReplicaSet Demo
01:34:14 Deployments
01:37:11 Deployment strategies
01:44:57 Deployments Demo
01:53:50 Deployment strategies Demo

Attach multiple VirtualServices to Istio Gateway

Peter Jausovec — Mon, 23 Nov 2020 20:43:25 +0000

What will I learn?

In this post, you'll learn how to expose multiple Kubernetes services running inside your cluster using Istio' Gateway and VirtualService resources.

The idea for this post came from a comment on the Istio Gateway video I recorded last year.

The question was: "Is it possible to route multiple VirtualServices using the same Gateway resource?".

The answer is YES. You can use the Gateway resource and bind multiple VirtualServices to it, exposing them outside of the cluster.

How does it work?

The key to understanding how to do that is in the hosts fields in the Gateway and VirtualService resources.

When you attach a VirtualService to a Gateway (using the gateway field), only the hosts defined in the Gateway resource will be allowed to make it to the VirtualService.

Let's look at the Gateway resource example, that defines two hosts: red.example.com and green.example.com:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: gateway
spec:
  selector:
    istio: ingressgateway
  servers:
    - port:
        number: 80
        name: http
        protocol: HTTP
      hosts:
        - 'red.example.com'
        - 'green.example.com'

With the hosts field, you can define one or more hosts you want to expose with the gateway. In this example, we are specifying the host with an FQDN name (e.g., red.example.com). We could optionally include a wildcard character (e.g. my-namespace/*) to select all VirtualService hosts from my-namespace. You can think of the list of hosts in the Gateway resource as a filter. For example, with the above definition, you are filtering the hosts down to red.example.com and green.example.com.

In addition to the Gateway, we also have two VirtualServices:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: red
spec:
  hosts:
    - 'red.example.com'
  gateways:
    - gateway
  http:
    - route:
        - destination:
            host: red.default.svc.cluster.local
            port:
              number: 80
--------
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: green
spec:
  hosts:
    - 'green.example.com'
  gateways:
    - gateway
  http:
    - route:
        - destination:
            host: green.default.svc.cluster.local
            port:
              number: 80

Notice that both VirtualServices are attached to the Gateway, allowing us to 'expose' the services (destinations) through the Gateway.

However, attaching the Gateway is not enough. We also need to specify the hosts in the VirtualService. Gateway uses the values in the hosts field to do the matching when the traffic comes in.

Let's take the red.example.com as an example. We make the following request:

$ curl -H "Host: red.example.com" http://$GATEWAY_URL

The request hits the ingress gateway (because we defined the host is in the hosts field in the Gateway resource), then, because we have a VirtualService with a matching host attached to the gateway, the traffic makes it to the destination (red.default.svc.cluster.local).

If we send a request to blue.example.com, we get back a 404. That's because we didn't specify that host name in the Gateways' hosts field. Even if we deployed a VirtualService that is attached to the gateway and has blue.example.com defined in its host field, we'd still get back a 404.

Try it out

To try this out on your cluster, following these steps:

Install Istio.
Label the default namespace for sidecar injection.
Deploy the Green and Red applications:

   kubectl apply -f https://raw.githubusercontent.com/peterj/color-app/main/examples/green.yaml

   kubectl apply -f https://raw.githubusercontent.com/peterj/color- app/main/examples/red.yaml

Create the Gateway, and VirtualServices:

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: gateway
spec:
  selector:
    istio: ingressgateway
  servers:
    - port:
        number: 80
        name: http
        protocol: HTTP
      hosts:
        - 'red.example.com'
        - 'green.example.com'
--------
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: red
spec:
  hosts:
    - 'red.example.com'
  gateways:
    - gateway
  http:
    - route:
        - destination:
            host: red.default.svc.cluster.local
            port:
              number: 80
--------
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: green
spec:
  hosts:
    - 'green.example.com'
  gateways:
    - gateway
  http:
    - route:
        - destination:
            host: green.default.svc.cluster.local
            port:
              number: 80

With everything deployed, we can try to make a request to the GATEWAY_URL.

You can use kubectl -n istio-system get service istio-ingressgateway -o jsonpath='{.status.loadBalancer.ingress[0].ip}' to get the GATEWAY_URL.

If you want to try this out in a browser, make sure you install an extension that allows you to modify the Host header. Alternatively, if you have access to an actual domain name, you can set the GATEWAY_URL as an A name record in your domain registrars' settings and use it directly.

You can refer to Expose a Kubernetes service on your own custom domain article to learn how to do that.

Let's make a request with Host set to green.example.com:

$ curl -H "Host: green.example.com" http://$GATEWAY_URL
<link href="/css/style.css" rel="stylesheet" type="text/css">
<link rel="preconnect" href="https://fonts.gstatic.com">
<link href="https://fonts.googleapis.com/css2?family=Montserrat:wght@500&display=swap" rel="stylesheet">

<div class="main" style="background-color:#10b981; color:#FFFFFF">
    <h1>GREEN</h1>
</div>

You get a similar response if you use red.example.com as your host.

Exploring Kubernetes Volumes

Peter Jausovec — Wed, 11 Nov 2020 20:43:25 +0000

Running stateful workloads inside Kubernetes is different from running stateless services. The reason being is that the containers and Pods can get created and destroyed at any time. If any of the cluster nodes go down or a new node appears, Kubernetes needs to reschedule the Pods.

If you ran a stateful workload or a database in the same way you are running a stateless service, all of your data would be gone the first time your Pod restarts.

Therefore you need to store the data outside of the container. Storing the data outside ensures that nothing happens to it when the container restarts.

The Volumes abstraction in Kubernetes solves the problem of storing data outside of containers problem. The Volume lives as long as the Pod lives. If any of the containers within the Pod get restarted, Volume preserves the data. However, once you delete the Pod, the Volume gets deleted as well.

The Volume is just a folder that may or may not have any data in it. The folder is accessible to all containers in a pod. How this folder gets created and the backing storage is determined by the volume type.

The most basic volume type is an empty directory (emptyDir). When you create a Volume with the emptyDir type, Kubernetes creates it when it assigns a Pod to a node. The Volume exists for as long as the Pod is running. As the name suggests, it is initially empty, but the containers can write and read from the Volume. Once you delete the Pod, Kubernetes deletes the Volume as well.

There are two parts to using the Volumes. The first one is the Volume definition. You can define the volumes in the Pod spec by specifying the volume name and the type (emptyDir in our case). The second part is mounting the Volume inside of the containers using the volumeMounts key. In each Pod you can use multiple different Volumes at the same time.

Inside the volume mount we refer to the Volume by name (pod-storage) and specifying which path we want to mount the Volume under (/data/).

Check out Getting started with Kubernetes to get set up your cluster and run through the examples in this post.

apiVersion: v1
kind: Pod
metadata:
  name: empty-dir-pod
spec:
  containers:
    - name: alpine
      image: alpine
      args:
        - sleep
        - "120"
      volumeMounts:
        - name: pod-storage
          mountPath: /data/
  volumes:
    - name: pod-storage
      emptyDir: {}

Save the above YAML in empty-dir-pod.yaml and run kubectl apply -f empty-dir.pod.yaml to create the Pod.

Next, we are going to use the kubectl exec command to get a terminal inside the container:

$ kubectl exec -it empty-dir-pod -- /bin/sh
/ # ls
bin dev home media opt root sbin sys usr
data etc lib mnt proc run srv tmp var

If you run ls inside the container, you will notice the data folder. The data folder is mounted from the pod-storage Volume defined in the YAML.

Let's create a dummy file inside the data folder and wait for the container to restart (after 2 minutes) to prove that the data inside the data folder stays around.

From inside the container create a hello.txt file under the data folder:

echo "hello" >> data/hello.txt

You can type exit to exit the container. If you wait for 2 minutes, the container will automatically restart. To watch the container restart, run the kubectl get po -w command from a separate terminal window.

Once container restarts, you can check that the file data/hello.txt is still in the container:

$ kubectl exec -it empty-dir-pod -- /bin/sh
/ # ls data/hello.txt
data/hello.txt
/ # cat data/hello.txt
hello
/ #

Kubernetes stores the data on the host under the /var/lib/kubelet/pods folder. That folder contains a list of pod IDs, and inside each of those folders is the volumes. For example, here's how you can get the pod ID:

$ kubectl get po empty-dir-pod -o yaml | grep uid
  uid: 683533c0-34e1-4888-9b5f-4745bb6edced

Armed with the Pod ID, you can run minikube ssh to get a terminal inside the host Minikube uses to run Kubernetes. Once inside the host, you can find the hello.txt in the following folder:

$ sudo cat /var/lib/kubelet/pods/683533c0-34e1-4888-9b5f-4745bb6edced/volumes/kubernetes.io~empty-dir/pod-storage/hello.txt
hello

If you are using Docker Desktop, you can run a privileged container and using nsenter run a shell inside all namespace of the process with id 1:

$ docker run -it --privileged --pid=host debian nsenter -t 1 -m -u -n -i sh
/ #

Once you get the terminal, the process is the same - navigate to the /var/lib/kubelet/pods folder and find the hello.txt just like you would if you're using Minikube.

Kubernetes supports a large variety of other volume types. Some of the types are generic, such as emtpyDir or hostPath (used for mounting folders from the nodes' filesystem). Other types are either used for cloud-provider storage (such as azureFile, awsElasticBlockStore, or gcePersistentDisk), network storage (cephfs, cinder, csi, flocker, ...), or for mounting Kubernetes resources into the Pods (configMap, secret).

Lastly, another particular type of Volumes are Persistent Volumes and Persistent Volume Claims.

The lack of the word "persistent" when talking about other volumes can be misleading. If you are using any cloud-provider storage volume types (azureFile or awsElasticBlockStore), the data will still be persisted. The persistent volume and persistent volume claims are just a way to abstract how Kubernetes provisions the storage.

For the full and up-to-date list of all volume types, check the Kubernetes Docs.

Send a Slack message when Docker images are updated

Peter Jausovec — Wed, 14 Oct 2020 20:43:25 +0000

The Kubernetes labs that are part of the Start Kubernetes course run as multiple Docker images inside a Kubernetes cluster. I wanted a way to notify the users when I push new Docker images to the registry. That way, they can restart the Pods and get the updated images.

The Azure container registry I use to host the images allows me to create webhooks. Whenever you push or delete an image, the container registry sends a JSON payload to a URL of my choosing.

For the course, I am using a Slack workspace. Slack also has support for apps. You can create and add apps to Slack workspaces and give them permission to post messages, for example. One of the Slack apps' features is the ability to use [incoming webhooks](https://api.slack.com/messaging/webhooks) to post messages to a Slack channel.

For example, you can configure a channel for the incoming webhook and then use a POST request like the one below to send a message to that channel:

curl -X POST -H 'Content-type: application/json' --data '{"text":"Hello, World!"}' https://hooks.slack.com/services/[somethingsomething]

Here's a diagram that shows what I wanted to achieve:

The issue I ran into quickly was that I couldn't control the payload that the container registry sends. You can only configure the URL and the headers you want to send. The container registry sends a payload that looks like this:

{
    "id": "673aeeaa-6493-41d3-bcdd-68242942bcb0",
    "timestamp": "2020-10-14T00:15:02.82330594Z",
    "action": "push",
    "target": {
        "mediaType": "application/vnd.docker.distribution.manifest.v2+json",
        "size": 1778,
        "digest": "sha256:a71f5e4bf56c05a3d6264b8ef4d3bb4c90b4b0af579fedb6ccb68ea59f597435",
        "length": 1778,
        "repository": "startkubernetes/sk-web",
        "tag": "1"
    },
    "request": {
        "id": "adbc2757-8d80-49ac-af5f-ec30e5147bdf",
        "host": "myregistry.azurecr.io",
        "method": "PUT",
        "useragent": "docker/19.03.13+azure go/go1.13.15 git-commit/bd33bbf0497b2327516dc799a5e541b720822a4c kernel/5.4.0-1026-azure os/linux arch/amd64 UpstreamClient(Docker-Client/19.03.13+azure \\(linux\\))"
    }
}

However, Slack is expecting a different looking payload. In its simplest form, the Slack message payload looks like this:

{
  "text": "This is my message"
}

Slack also has a Block Kit Builder that allows you to build more complex messages.

In any case, I needed an intermediary that does the following:

Accepts the container registry payload
Extracts the information (repository, tag, and a timestamp)
Creates payload that Slack understands
Sends the payload to the Slack incoming webhook URL.

That seemed like a perfect use case for a serverless function. The function has an endpoint, and I can use that in the container registry webhook. The webhook sends the container registry payload to my function. In the function, I can write any code I want, modify the payload, and then it to the Slack webhook.

To create the function, I downloaded the Azure Functions VS Code extension, logged in, and I was able to do everything from my editor.

Here's how the function looks like:

const axios = require('axios');
const slackUrl =
  'https://hooks.slack.com/services/[somethingsomething]';

module.exports = async function (context, req) {
  let message = JSON.stringify(req.body);

  if (
    req.body.hasOwnProperty('target') &&
    req.body.hasOwnProperty('timestamp')
  ) {
    const {
      target: { repository, tag },
      timestamp,
    } = req.body;
    message = `Pushed image ${repository}:${tag} (${timestamp})`;
  } else {
    context.res = {
      status: 500,
      body: req.body,
    };
    return;
  }

  axios
    .post(
      slackUrl,
      { text: message },
      {
        headers: {
          'content-type': 'application/json',
        },
      }
    )
    .then((response) => {
      context.res = { body: response.body };
    })
    .catch((err) => {
      context.res = {
        status: 500,
        body: err,
      };
      context.done();
    });
};

I deployed the function, then updated the container registry webhook to send the payloads to the function URL, and that was it. The container registry webhook has the option of sending a Ping to the endpoint. That way you, can test out the connection. Similarly, if I wanted to test the function-to-Slack connection, I could either send a POST request directly to the Slack, or manually invoke the function.

Every time I make changes to the labs or any code, and when I merge a PR to the main branch, the Github action builds the images and pushes them to the registry. Then, registry takes over, sends the payload to the function and sends the message to a Slack channel.

Kubernetes Network Policy

Peter Jausovec — Wed, 07 Oct 2020 20:43:25 +0000

Network Policy

Using the NetworkPolicy resource, you can control the traffic flow for your applications in the cluster, at the IP address level or port level (OSI layer 3 or 4).

Open Systems Interconnection model (OSI model) is a conceptual model that characterises and standardizes the communication functions, regardless of the underlying technology. For more information, see the OCI model.

With the NetworkPolicy you can define how your Pod can communicate with various network entities in the cluster. There are three parts to defining a NetworkPolicy:

Select the Pods the policy applies to. You can do that using labels. For example, using app=hello applies the policy to all Pods with that label.
Decide if the policy applies for incoming (ingress) traffic, outgoing (egress) traffic, or both.
Define the ingress or egress rules by specifying IP blocks, ports, Pod selectors, or namespace selectors.

Here is a sample NetworkPolicy:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: my-network-policy
  namespace: default
spec:
  podSelector:
    matchLabels:
      app: hello
  policyTypes:
  - Ingress
  - Egress
  ingress:
  - from:
    - ipBlock:
        cidr: 172.17.0.0/16
        except:
        - 172.17.1.0/24
    - namespaceSelector:
        matchLabels:
          owner: ricky 
    - podSelector:
        matchLabels:
          version: v2
    ports:
    - protocol: TCP
      port: 8080
  egress:
  - to:
    - ipBlock:
        cidr: 10.0.0.0/24
    ports:
    - protocol: TCP
      port: 500

Let's break down the above YAML. The podSelector tells us that the policy applies to all Pods in the default namespace that have the app: hello label set. We are defining policy for both ingress and egress traffic.

The calls to the Pods policy applies to can be made from any IP within the CIDR block 172.17.0.0/16 (that's 65536 IP addresses, from 172.17.0.0 to 172.17.255.255), except for Pods whose IP falls within the CIDR block 172.17.1.0/24 (256 IP addresses, from 172.17.1.0 to 172.17.1.255) to the port 8080. Additionally, the calls to the Pods policy applies to can be coming from any Pod in the namespace(s) with the label owner: ricky and any Pod from the default namespace, labeled version: v2.

The egress policy specifies that Pods with the label app: hello in the default namespace can make calls to any IP within 10.0.0.0/24 (256 IP addresses, from 10.0.0.0, 10.0.0.255), but only to the port 5000.

The Pod and namespace selectors support and and or semantics. Let's consider the following snippet:

  ...
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          user: ricky
      podSelector:
        matchLabels:
          app: website
  ...

The above snippet with a single element in the from array, includes all Pods with labels app: website from the namespace labeled user: ricky. This is the equivalent of and operator.

If you change the podSelector to be a separate element in the from array by adding -, you are using the or operator.

  ...
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          user: ricky
    - podSelector:
        matchLabels:
          app: website
  ...

The above snippet includes all Pods labeled app: website or all Pods from the namespace with the label user: ricky.

Install Cilium

Network policies are implemented (and rules enforced) through network plugins. If you don't install a network plugin, the policies won't have any effect.

I will use the Cilium plugin and install it on top of Minikube. You could also use a different plugin, such as Calico.

If you already have Minikube running, you will have to stop and delete the cluster (or create a new one). You will have to start Minikube with the cni flag for the Cilium to work correctly:

$ minikube start --network-plugin=cni

Once Minikube starts, you can install Cilium.

$ kubectl create -f https://raw.githubusercontent.com/cilium/cilium/1.8.3/install/kubernetes/quick-install.yaml
all/kubernetes/quick-install.yaml
serviceaccount/cilium created
serviceaccount/cilium-operator created
configmap/cilium-config created
clusterrole.rbac.authorization.k8s.io/cilium created
clusterrole.rbac.authorization.k8s.io/cilium-operator created
clusterrolebinding.rbac.authorization.k8s.io/cilium created
clusterrolebinding.rbac.authorization.k8s.io/cilium-operator created
daemonset.apps/cilium created
deployment.apps/cilium-operator created

Cilium is installed in kube-system namespace, so you can run kubectl get po -n kube-system and wait until the Cilium Pods are up and running.

Example

Let's look at an example that demonstrates how to disable egress traffic from the Pods.

apiVersion: v1
kind: Pod
metadata:
  name: no-egress-pod
  labels:
    app.kubernetes.io/name: hello
spec:
  containers:
    - name: container
      image: radial/busyboxplus:curl
      command: ["sh", "-c", "sleep 3600"]

Save the above YAML to no-egress-pod.yaml and create the Pod using kubectl apply -f no-egress-pod.yaml.

Once the Pod is running, let's try calling google.com using curl:

$ kubectl exec -it no-egress-pod -- curl -I -L google.com
HTTP/1.1 301 Moved Permanently
Location: http://www.google.com/
Content-Type: text/html; charset=UTF-8
Date: Thu, 24 Sep 2020 16:30:59 GMT
Expires: Sat, 24 Oct 2020 16:30:59 GMT
Cache-Control: public, max-age=2592000
Server: gws
Content-Length: 219
X-XSS-Protection: 0
X-Frame-Options: SAMEORIGIN

HTTP/1.1 200 OK
...

The call completes successfully. Let's define a network policy that will prevent egress for Pods with the label app.kubernetes.io/name: hello:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-egress
spec:
  podSelector:
    matchLabels:
      app.kubernetes.io/name: hello
  policyTypes:
    - Egress

If you run the same command this time, curl won't be able to resolve the host:

$ kubectl exec -it no-egress-pod -- curl -I -L google.com
curl: (6) Couldn't resolve host 'google.com'

Try running kubectl edit pod no-egress-pod and change the label value to hello123. Save the changes and then re-run the curl command. This time, the command works fine because we changed the Pod label, and the network policy does not apply to it anymore.

Common Network Policies

Let's look at a couple of scenarios and corresponding network policies.

Deny all egress traffic

Denies all egress traffic from the Pods in the namespace, so Pods cannot make any outgoing requests.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-egress
spec:
  podSelector: {}
  policyTypes:
    - Egress

Deny all ingress traffic

Denies all ingress traffic, and Pods cannot receive any requests.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: deny-all-ingress
spec:
  podSelector: {}
  policyTypes:
    - Ingress

Allow ingress traffic to specific Pods

Allow ingress to specific Pods, identified by the label app: my-app.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: pods-allow-all
spec:
  podSelector:
    matchLabels:
      app: my-app
  ingress:
    - {}

Deny ingress to specific Pods

Denies ingress to specific Pods, identified by the label app: my-app.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: pods-deny-all
spec:
  podSelector:
    matchLabels:
      app: my-app
  ingress: []

Restrict traffic to specific Pods

Allows traffic from certain Pods only. Allow traffic from app: customers to any frontend Pods (role: frontend) that are part of the same app (app: customers).

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: frontend-allow
spec:
  podSelector:
    matchLabels:
      app: customers
      role: frontend
  ingress:
    - from:
        - podSelector:
            matchLabels:
              app: customers

Deny all traffic to and within a namespace

Denies all incoming traffic (no ingress rules defined) to all Pods (empty podSelector) in the prod namespace. Any calls from outside of the default namespace will be blocked and any calls between Pods in the same namespace.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: prod-deny-all
  namespace: prod
spec:
  podSelector: {}
  ingress: []

Deny all traffic from other namespaces

Denies all traffic from other namespaces, coming to the Pods in the prod namespace. It matches all pods (empty podSelector) in the prod namespace and allows ingress from all Pods in the prod namespace, as the ingress podSelector is empty as well.

kind: NetworkPolicy
apiVersion: networking.k8s.io/v1
metadata:
  name: deny-other-namespaces
  namespace: prod
spec:
  podSelector: {}
  ingress:
    - from:
        - podSelector: {}

Deny all egress traffic for specific Pods

Denies Pods labeled with app: api from making any external calls.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: api-deny-egress
spec:
  podSelector:
    matchLabels:
      app: api
  policyTypes:
    - Egress
  egress: []

Sidecar Container Pattern

Peter Jausovec — Mon, 05 Oct 2020 03:30:25 +0000

The sidecar container aims to add or augment an existing container's functionality without changing the container. In comparison to the init container, we discussed previously, the sidecar container starts and runs simultaneously as your application container. The sidecar is just a second container you have in your container list, and the startup order is not guaranteed.

Probably one of the most popular implementations of the sidecar container is in Istio service mesh. The sidecar container (an Envoy proxy) is running next to the application container and intercepting inbound and outbound requests. In this scenario, the sidecar adds the functionality to the existing container and allows the operator to do traffic routing, failure injection, and other features.

A simpler idea might be having a sidecar container (log-collector) that collects and stores application container's logs. That way, as an application developer, you don't need to worry about collecting and storing logs. You only need to write logs to a location (a volume, shared between the containers) where the sidecar container can collect them and send them to further processing or archive them.

If we continue with the example we used for the init container; we could create a sidecar container that periodically updates runs git pull and updates the repository. For this to work, we will keep the init container to do the initial clone, and a sidecar container that will periodically (every 60 seconds for example) check and pull the repository changes.

To try this out, make sure you fork the original Github repository and use your fork in the YAML below.

apiVersion: v1
kind: Pod
metadata:
  name: website
spec:
  initContainers:
    - name: clone-repo
      image: alpine/git
      command:
        - git
        - clone
        - --progress
        - https://github.com/peterj/simple-http-page.git
        - /usr/share/nginx/html
      volumeMounts:
        - name: web
          mountPath: "/usr/share/nginx/html"
  containers:
    - name: nginx
      image: nginx
      ports:
        - name: http
          containerPort: 80
      volumeMounts:
        - name: web
          mountPath: "/usr/share/nginx/html"
    - name: refresh
      image: alpine/git
      command:
        - sh
        - -c
        - watch -n 60 git pull
      workingDir: /usr/share/nginx/html
      volumeMounts:
        - name: web
          mountPath: "/usr/share/nginx/html"
  volumes:
    - name: web
      emptyDir: {}

We added a container called refresh to the YAML above. It uses the alpine/git image, the same image as the init container, and runs the watch -n 60 git pull command.

The watch command periodically executes a command. In our case, it executes git pull command and updates the local repository every 60 seconds.

Another field we haven't mentioned before is workingDir. This field will set the working directory for the container. We are setting it to /usr/share/nginx/html as that's where we originally cloned the repo to using the init container.

Save the above YAML to sidecar-container.yaml and create the Pod using kubectl apply -f sidecar-container.yaml.

If you run kubectl get pods once the init container has executed, you will notice the READY column now shows 2/2. These numbers tell you right away that this Pod has a total of two containers, and both of them are ready:

$ kubectl get po
NAME READY STATUS RESTARTS AGE
website 2/2 Running 0 3m39s

If you set up the port forward to the Pod using kubectl port-forward pod/website 8000:80 command and open the browser to http://localhost:8000, you will see the same webpage as before.

We can open a separate terminal window and watch the logs from the refresh container inside the website Pod:

$ kubectl logs website -c refresh -f

Every 60.0s: git pull
Already up to date.

The watch command is running, and the response from the last git pull command was Already up to date. Let's make a change to the index.html in the repository you forked.

I added <div> element and here's how the updated index.html file looks like:

<html>
  <head>
    <title>Hello from Simple-http-page</title>
  </head>
  <body>
    <h1>Welcome to simple-http-page</h1>
    <div>Hello!</div>
  </body>
</html>

Next, you need to stage this and commit it to the master branch. The easiest way to do that is from the Github's webpage. Open the index.html on Github (I am opening https://github.com/peterj/simple-http-page/blob/master/index.html, but you should replace my username peterj with your username or the organization you forked the repo to) and click the pencil icon to edit the file (see the figure below).

Make the change to the index.html file and click the Commit changes button to commit them to the branch. Next, watch the output from the refresh container, and you should see the output like this:

Every 60.0s: git pull

From https://github.com/peterj/simple-http-page
   f804d4c..ad75286 master -> origin/master
Updating f804d4c..ad75286
Fast-forward
 index.html | 1 +
 1 file changed, 1 insertion(+)

The above output indicates changes to the repository. Git pulls the updated file to the shared volume. Finally, refresh your browser where you have http://localhost:8000 opened, and you will notice the changes on the page:

You can make more changes, and each time, the page will get updated within 60 seconds. You can delete the Pod by running kubectl delete po website.

Ambassador Container Pattern

Peter Jausovec — Sat, 03 Oct 2020 20:43:25 +0000

The ambassador container pattern aims to hide the primary container's complexity and provide a unified interface through which the primary container can access services outside of the Pod.

These outside or external services might present different interfaces and have other APIs. Instead of writing the code inside the main container that can deal with these external services' multiple interfaces and APIs, you implement it in the ambassador container. The ambassador container knows how to talk to and interpret responses from different endpoints and pass them to the main container. The main container only needs to know how to talk to the ambassador container. You can then re-use the ambassador container with any other container that needs to talk to these services while maintaining the same internal interface.

Another example would be where your main containers need to make calls to a protected API. You could design your ambassador container to handle the authentication with the protected API. Your main container will make calls to the ambassador container. The ambassador will attach any needed authentication information to the request and make an authenticated request to the external service.

To demonstrate how the ambassador pattern works, we will use The Movie DB (TMBD). Head over to the website and register (it's free) to get an API key.

The Movie DB website offers a REST API where you can get information about the movies. We have implemented an ambassador container that listens on path /movies, and whenever it receives a request, it will make an authenticated request to the API of The Movie DB.

Here's the snippet from the code of the ambassador container:

func TheMovieDBServer(w http.ResponseWriter, r *http.Request) {
    apiKey := os.Getenv("API_KEY")
    resp, err := http.Get(fmt.Sprintf("https://api.themoviedb.org/3/discover/movie?api_key=%s", apiKey))
    // ...
    // Return the response
}

We will read the API_KEY environment variable and then make a GET request to the URL. Note if you try to request to URL without the API key, you'll get the following error:

$ curl https://api.themoviedb.org/3/discover/movie
{"status_code":7,"status_message":"Invalid API key: You must be granted a valid key.","success":false}

I have pushed the ambassador's Docker image to startkubernetes/ambassador:0.1.0.

Just like with the sidecar container, the ambassador container is just another container that's running in the Pod. We will test the ambassador container by calling curl from the main container.

Here's how the YAML file looks like:

apiVersion: v1
kind: Pod
metadata:
  name: themoviedb
spec:
  containers:
    - name: main
      image: radial/busyboxplus:curl
      args:
        - sleep
        - "600"
    - name: ambassador
      image: startkubernetes/ambassador:0.1.0
      env:
        - name: API_KEY
          valueFrom:
            secretKeyRef:
              name: themoviedb
              key: apikey
      ports:
        - name: http
          containerPort: 8080

Before we can create the Pod, we need to create a Secret with the API key. Let's do that first:

$ kubectl create secret generic themoviedb --from-literal=apikey=<INSERT YOUR API KEY HERE>
secret/themoviedb created

You can now store the Pod YAML in ambassador-container.yaml file and create it with kubectl apply -f ambassador-container.yaml.

When Kubernetes creates the Pod (you can use kubectl get po to see the status), you can use the exec command to run the curl command inside the main container:

$ kubectl exec -it themoviedb -c main -- curl localhost:8080/movies

{"page":1,"total_results":10000,"total_pages":500,"results":[{"popularity":2068.491,"vote_count":
...

Since containers within the same Pod share the network, we can make a request against localhost:8080, which corresponds to the port on the ambassador container.

You could imagine running an application or a web server in the main container, and instead of making requests to the api.themoviedb.org directly, you are making requests to the ambassador container.

Similarly, if you had any other service that needed access to the api.themoviedb.org you could add the ambassador container to the Pod and solve access like that.

Start Kubernetes for Beginners

Peter Jausovec — Thu, 01 Oct 2020 20:43:25 +0000

I am excited to announce my latest course on Kubernetes called Start Kubernetes.

Why this course?

I have started working with Kubernetes years ago, and I remember the confusion when I heard about Pods and Services and how things work in Kubernetes. I've been using Marathon/Mesos at that point, so the concepts were a bit familiar, but still foreign. I noticed I was able to grasp the concepts quicker through practical exercises and examples.

Talking about complexity, even today, if you want to deploy and run an application inside Kubernetes, you have to:

Create a Deployment representing your application
Design the Pods, set the resource limits, requests, and security settings
Create a Service, so that you can access the application
Define any Configuration and Secrets your application will use
Configure or reconfigure Ingress

That's on top of being familiar with how Pods, Deployments, Services, Ingress, and other Kubernetes resources work. Of course, there are other knobs and buttons you can turn and push to fine-tune each one of these resources. No one can deny there is a lot of complexity and new terminology.

I have created this course to try, and flatten the learning curve of Kubernetes , explaining the individual concepts and resources, show how everything fits together, and then bring it together with practical examples.

Course overview

There are three parts to the course: the e-book, the video course, and the practical exercises/labs.

The book

This whole course started as a long Kubernetes article and it ended up as a 230+ page book where I cover the following topics:

Kubernetes Resources

An overview of Pods, ReplicaSets, Deployments, Services, Ingress, Namespaces, Jobs, CronJobs, and things like labels, selectors, and annotations

Configuration

How to configure your Kubernetes applications with ConfigMaps and how to store and use Secrets

Stateful Workloads

Introduction to Volumes, Persistent Volumes, and Persistent Volume Claims, and how to run stateful workloads in Kubernetes using StatefulSets

Organizing Containers

Init, sidecar, ambassador, and adapter container patterns with practical examples

Application Health

Explanation of liveness, startup, and readiness probes

Security in Kubernetes

Services accounts, using RBAC, security contexts, and Pod security policies

Scaling and Resources

Autoscaling Pods using HorizontalPodAutoscaler, defining resource requests and limits; using affinity, taints, and tolerations

Extending Kubernetes

Using custom resource definitions (CRDs), implementing controllers/operators

Videos

I enjoy writing, but I also enjoy making videos, so I decided to turn the book into the video course. If you're a visual learner as I am, you will enjoy this. I have recorded 23 videos that walk you through different Kubernetes topics, starting with basic resources, such as Pods and Deployments, and role-based access control and creating your own custom resources and controllers.

The full list of videos is below. You can also check out the first four videos on my YouTube channel:

About Pods (3:37)
Creating Pods (5:16)
About ReplicaSets (2:38)
Creating ReplicaSets (12:20)
Deployments (10:32)
Deployment Strategies (11:03)
Services (17:35)
Service Types (9:20)
About Ingress (3:13)
Creating Ingress (18:30)
Jobs (9:38)
CronJob (6:11)
About Configuration (2:10)
ConfigMaps (17:23)
Secrets (10:15)
Volumes (6:24)
About PV and PVC (2:30)
Creating PV and PVC (6:40)
Running MongoDB with StatefulSet (9:26)
Service Accounts (10:07)
Role-Based Access Control (RBAC) (9:56)
Resource Requests, Limits, and Quotas (13:42)
CRDs and Controllers (18:21)

Practical exercises

Reading and watching can become tedious, so I have created 41 practical exercises. You will install the Start Kubernetes Labs on your Kubernetes cluster, and go through the exercises from your browser.

I have grouped tasks/exercises into seven categories, and each category has from 3 to 10 tasks. Tasks have a detailed description of what needs to be solved, and you can use the built-in terminal on the webpage to solve the exercises. From the terminal, you have access to the Kubernetes cluster via the CLI.

You can solve the exercises in order, or jump from one to another - however you feel most comfortable learning. There's no timers, scores, or leaderboards. If you're still stuck, you can hop on the Slack channel, explain the issue you're running into, and we will solve it together. The point of these exercises is to learn and get better at Kubernetes.