gravitational / workshop

Docker, Kubernetes and Gravity Trainings by Gravitational

Gravitational Workshops

Warning

The Gravitational Workshops were archived 2023-07-01, as Gravitational no longer offers Kubernetes or Gravity training.

Please see our Gravitational is Teleport blog post for more information.

Open source series of workshops delivered by the Gravitational team.

• Docker 101 workshop
• Kubernetes 101 workshop using Minikube and Mattermost
• Kubernetes production patterns
• Kubernetes security patterns
• Kubernetes custom resources
• Gravity 101
• Gravity fire drill exercises
• Gravity logging (Gravity 5.5 and earlier)
• Gravity logging (Gravity 6.0 and later)
• Gravity monitoring & alerts (Gravity 5.5 and earlier)
• Gravity monitoring & alerts (Gravity 6.0 and later)
• Gravity networking and network troubleshooting
• Gravity upgrade (5.5)
• Gravity upgrade (7.0)

Installation

Requirements

You will need a Linux or macOS box with at least 7GB of RAM and 20GB of free disk space available.

Docker

For Linux: follow instructions provided here.

If you have macOS (Yosemite or newer), please download Docker for Mac here.

Older docker package for OSes older than Yosemite -- Docker Toolbox located here.

Hypervisor

HyperKit [macOS only]

HyperKit is a lightweight macOS hypervisor which minikube supports out of the box and which should be already installed on your machine if you have Docker for Desktop installed.

More information: https://minikube.sigs.k8s.io/docs/reference/drivers/hyperkit/.

Alternatively, install VirtualBox like described below.

KVM2 [Linux only]

Follow the instructions here: https://minikube.sigs.k8s.io/docs/reference/drivers/kvm2/.

Alternatively, install VirtualBox like described below.

VirtualBox [both macOS and Linux]

Let’s install VirtualBox.

Get latest stable version from https://www.virtualbox.org/wiki/Downloads.

Note: When using Ubuntu you may need to disable Secure Boot. For an alternative approach to installing with Secure Boot enabled, follow the guide here.

Kubectl

For macOS:

curl -O https://storage.googleapis.com/kubernetes-release/release/v1.16.2/bin/darwin/amd64/kubectl \
    && chmod +x kubectl && sudo mv kubectl /usr/local/bin/

For Linux:

curl -O https://storage.googleapis.com/kubernetes-release/release/v1.16.2/bin/linux/amd64/kubectl \
    && chmod +x kubectl && sudo mv kubectl /usr/local/bin/

Minikube

For macOS:

curl -Lo minikube https://storage.googleapis.com/minikube/releases/v1.5.1/minikube-darwin-amd64 \
    && chmod +x minikube && sudo mv minikube /usr/local/bin/

For Linux:

curl -Lo minikube https://storage.googleapis.com/minikube/releases/v1.5.1/minikube-linux-amd64 \
    && chmod +x minikube && sudo mv minikube /usr/local/bin/

Also, you can install drivers for various VM providers to optimize your minikube VM performance. Instructions can be found here: https://github.com/kubernetes/minikube/blob/master/docs/drivers.md.

Xcode and local tools

Xcode will install essential console utilities for us. You can install it from the App Store.

Set up cluster using minikube

To run cluster:

macOS

# starts minikube
$ minikube start --kubernetes-version=v1.16.2
# this command should work
$ kubectl get nodes
# use docker from minikube
$ eval $(minikube docker-env)
# this command to check connectivity
$ docker ps

Linux

# starts minikube
$ minikube start --kubernetes-version=v1.16.2 --vm-driver=kvm2
# this command should work
$ kubectl get nodes
# use docker from minikube
$ eval $(minikube docker-env)
# this command to check connectivity
$ docker ps

Clone the Workshop repository

$ git clone https://github.com/gravitational/workshop.git
$ cd workshop

Configure registry

$ kubectl create -f registry.yaml

workshop's Issues

Update worker.yaml in k8s101

Update worker.yaml (line 21) in mattermost directory in k8s101 workshop

Currently states:

image: mattermost-worker:2.1.0

Prefix image with registry for example:

image: $registry/mattermost-worker:2.1.0

Better README instructions

The README should explicitly mention that this repo should be cloned and placed somewhere and that registry.yaml is in the repo.

gravity101 - alpine pod is installed in kube-system namespace

When following gravity101 training, it was noticed that the alpine pod get's installed in the kube-system namespace when using the v1 prebuilt version.

Update Gravity Workshops to Latest LTS Version

The Gravity version used in Gravity 101 should be updated to the latest LTS version. https://gravitational.com/gravity/docs/changelog/

Update ubuntu version used in workshop

Current ubuntu version used in workshop is 14.04 - this should be updated to a later version in the readme files + related files that mention ubuntu verion 14.04.

Docker 101 Training Feedback

Capturing some feedback from latest training workshop related to Docker 101 section:

*Incorporate best practices for writing dockerfile
*Developer experience, at what point to introduce docker at your company (may be a decent blog post?)
*Most common pitfalls from adopting docker

Add Gravity Logging Section for 6.X+

Current Logging Workshop section pertains specifically to Gravity 5.5 and earlier.

Logging stack has changed in 6.X+, training should be expanded to reflect the changes.

Be consistent about if :5000 is included in the registrry variable or not

I would much prefer the k8s101.md version. So you can easily use an external registry.

k8s101.md:$ export registry="$(kubectl get svc/registry -ojsonpath='{.spec.clusterIP}'):5000"
k8sprod.md:$ export registry=$(kubectl get svc/registry -ojsonpath="{.spec.clusterIP}")

Add Monitoring/Alerts Section for Gravity 6.X+ discuss setup of Prometheus

Current Monitoring/Alerts section pertains to Gravity 5.5 and earlier

This task covers extending the training section to involve Gravity 6.X+

Also a new section should be added to the Monitoring/Alerts discuss setup of Prometheus to scrape metrics from a custom pod/deployment. Some customers have been looking at running a simple pod and would like to see the metrics scraped from it to the default monitoring gravity UI console. In discussion with Roman, the suggested approached would be:

Since we’re just deploying a Prometheus Operator (https://github.com/coreos/prometheus-operator) to configure it to scrape metrics from a given service, you can either create additional scrape config (https://github.com/coreos/prometheus-operator/blob/master/Documentation/additional-scrape-config.md) or declare it via a ServiceMonitor resource (it’s described in https://github.com/coreos/prometheus-operator/blob/master/Documentation/user-guides/getting-started.md).

Then, you will need to create a Grafana dashboard and how to plug it into our UI is described in https://gravitational.com/gravity/docs/monitoring/#grafana-integration.

Add section for log forwarder

Add some discussion or section on log forwarder:

• How log forwarder works
• How to customize
• How to troubleshoot (can be discussed in fire drills)

Add section for monitoring/alerts

Add some sections or context around monitoring and alerts during training workshop. Some notes and possible topics to be added:

SMTP & Alerts:

• What metrics are monitored in alertmanager
• How to debug SMTP
• How to customize the alerts script

Monitoring:

• How it works
• Granularity of metrics
• What metrics are monitored

Add more information to readiness probes

As discussed here sometimes it´s not only necessary to gracefully shutdown (your might also want to mention graceful shutdowns in the doc) but also to call a pre-stop lifecycle hook.

Only this will ensure that the pod is being taken out of the service endpoint list before getting SIGTERM/ SIGKILL (depending on the termination policy).

How to reproduce: Try to hammer the service during scale-in or rolling update with "go-wrk" or "hey" tools to see connections being dropped.