Academy on Exoscale Academy

Introduction to Compliance

Mon, 01 Jan 0001 00:00:00 +0000

Why Compliance? 🔗

Is essential for business. 🔗

Companies that comply with regulations are usually more competitive than those that don’t, as they can offer their products through any marketplace without any legal restriction.
Customers have more trust in those companies because they know they’re following quality standards and using safe materials for consumption.
Learning more about compliance and why it is essential can help implement workplace programs that follow established policies, codes, and standards.

Introduction to DBaaS

Mon, 01 Jan 0001 00:00:00 +0000

Data 🔗

Data is the fuel of our society. Can we agree on that? There were many bold statements over the years to underline the importance of data. Data is the new oil; Data is the new gold; all variations you have probably come across if you follow the news, media, or social media. Data is the new water - is a fresh analogy you can find in researching the data topic.

Introduction to Kubernetes

Mon, 01 Jan 0001 00:00:00 +0000

Experiences we want to change! 🔗

Why Containers? 🔗

Many people have a complex job building, testing, and running systems based on old concepts and technology in today’s IT — the results you can see below (Experiences we want to change!). Modern ways to build, test, and run IT systems are not adopted as broadly as possible. Hence, a lot of pain is still out there that we could ease by changing IT processes and utilizing the new ways.

Introduction to Pricing

Mon, 01 Jan 0001 00:00:00 +0000

Typical Web Application 🔗

Our example architecture consists of the following explained components, and it demonstrates the practical usage of several products together and the associated costs.

Application Servers 🔗

run the web application. The application reads from the DB servers via the Elastic IP v2, and users access this web service via another Elastic IP v2 that distributes traffic evenly among them. Upload user files to the Public File Bucket. Installed in an Anti-Affinity group.

Introduction to Storage

Mon, 01 Jan 0001 00:00:00 +0000

Storage 🔗

Definition 🔗

Storage is crucial for preserving and accessing computer data, files, applications, and other digital content. Storage refers to the process of storing and retrieving data or information. It is an essential component of any computer system.

Basic Storage Types 🔗

There are several basic types of storage that are commonly used in computing systems. Here are the most common types:

Introduction to Sustainability

Mon, 01 Jan 0001 00:00:00 +0000

Corporate Sustainability (CS) 🔗

Why? 🔗

Long-term Viability: Businesses prioritizing sustainability are better equipped to navigate the risks associated with resource scarcity, climate change, and evolving regulatory landscapes. A sustainable approach helps ensure long-term viability in a rapidly changing world.
Competitive Advantage: As consumers, investors, and other stakeholders increasingly value sustainability, companies committed to sustainable practices can differentiate themselves in the marketplace. This can translate into increased brand loyalty, attract investment, and open new markets.

Certified Cloud Professional

Mon, 01 Jan 0001 00:00:00 +0000

Cloud Computing 🔗

Definition 🔗

Cloud computing lets you use servers, storage, and applications on the Internet instead of owning or managing your own hardware. It’s an easy, flexible, and cost-effective way to get the technology you need without the hassle.

Service Models 🔗

Explained 🔗

Cloud service models let you easily use software, development tools, or virtual computers over the Internet. This gives your organization more flexibility and the ability to grow, without having to manage complex IT systems yourself.

Certified Container Engineer

Mon, 01 Jan 0001 00:00:00 +0000

Container 🔗

Application Deployment 🔗

Observing the evolution of application deployment highlights the advantages that containers offer.

Traditional Deployment 🔗

Initially, organizations ran applications directly on physical servers, lacking resource boundaries between applications. This often led to resource contention and underperformance. Running each application on its own server solved this but resulted in underutilized resources and high costs.

Certified Solution Architect

Mon, 01 Jan 0001 00:00:00 +0000

Overview 🔗

IaaS+ 🔗

Infrastructure as a Service is the cloud service model we support with the Exoscale platform and a bit more, hence, IaaS+.

VIDEO 🔗

IaaS+

Data Centers 🔗

Getting the necessary cloud infrastructure components is easy. In Europe, there is always an Exoscale data center near you.

Instructor Toolkit

Mon, 01 Jan 0001 00:00:00 +0000

Ready to publish

All publishable content IDs are registered.

⚠️Draft page: Content ID is not registered or missing. ❌Content ID is not registered or missing. ✅ Content ID is registered.

Page	Draft	Content ID	Status
Certified Cloud Professional	False	033b0a08-0ac5-4073-a343-fcabda7730f1	✅
Certified Solution Architect	False	b4b20bf2-a034-4724-9cca-c370c477418e	✅
Certified Container Engineer	False	ad28e9ed-b1e5-4d90-aa62-43bf32c2e4f5	✅
INTRO Kubernetes	False	6bb2ae92-89d6-4e2b-aac2-74512828b68d	✅
INTRO DBaaS	False	3dd8409e-ba0f-4d0c-ae4b-b2ee3d3361fd	✅
INTRO Storage	False	c2326b60-4cb4-4f82-acdb-f9e5a32c3304	✅
INTRO Sustainability	False	70c37467-6d35-44c8-a1bc-d4be86981592	✅
INTRO Compliance	False	d2693f33-9afe-46c0-bf21-65a15ba983ac	✅
INTRO Pricing	False	7dc9d1fa-063c-4ff5-8a13-7250baee1f09	✅
Workshop Kubernetes	False	8cd4aa89-87f5-472d-a7c2-69e5b9819915	✅
Workshop CKA Preparation	False	5a817fbd-7754-4bf2-8285-be3074c854ea	✅
Workshop Exoscale Intro	False	0e8df4e6-ed92-4687-a84f-c3dc61af912c	✅

Solution - Audit

Mon, 01 Jan 0001 00:00:00 +0000

On the controlplane node, create the file /etc/kubernetes/audit-policy.yaml with the following content:
```
apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: Metadata
```

Edit the API Server Pod specification (in the file /etc/kubernetes/manifests/kube-apiserver.yaml) by adding the following two volume definitions:

- name: audit
 hostPath:
 path: /etc/kubernetes/audit-policy.yaml
 type: File
- name: audit-log
 hostPath:
 path: /var/log/kubernetes/audit/
 type: DirectoryOrCreate

and also add the following entries to the volumeMounts field of the container:

- mountPath: /etc/kubernetes/audit-policy.yaml
 name: audit
 readOnly: true
- mountPath: /var/log/kubernetes/audit/
 name: audit-log
 readOnly: false

Start a simple Pod:

Solution - Certs

Mon, 01 Jan 0001 00:00:00 +0000

Check the current certificate expiration dates

Run the following command from the control plane node.

sudo kubeadm certs check-expiration

This command shows all certificates managed by kubeadm and their expiration dates:

admin.conf (client certificate for kubectl)
apiserver (API server serving certificate)
apiserver-etcd-client (API server to etcd client certificate)
apiserver-kubelet-client (API server to kubelet client certificate)
controller-manager.conf (controller manager client certificate)
etcd-healthcheck-client (etcd health check client certificate)
etcd-peer (etcd peer certificate for cluster communication)
etcd-server (etcd server certificate)
front-proxy-client (front proxy client certificate)
scheduler.conf (scheduler client certificate)
super-admin.conf (client certificate bypassing authorization layer)

By default, kubeadm certificates are valid for 1 year. You should renew them before they expire to avoid cluster outages.
Certificate are automatically renewed during each upgrade of the control plane.

Renew the certificates using kubeadm

You can renew all certificates at once.

Solution - Ch1

Mon, 01 Jan 0001 00:00:00 +0000

Test

If you try to list the Nodes, you’ll get an error similar to the following one:

$ kubectl get no

The connection to the server 192.168.64.17:6443 was refused - did you specify the right host or port?

Identification

As kubectl targets the API Server, first make sure this one is running fine.

On the controlplane Node, check the APIServer’s logs in /var/log/syslog. You should see that the API Server cannot start correctly:

Solution - Ch2

Mon, 01 Jan 0001 00:00:00 +0000

The worker1 has the NotReady status

$ kubectl get no
NAME STATUS ROLES AGE VERSION
master Ready control-plane,master 2d16h v1.32.7
worker1 NotReady <none> 2d16h v1.32.7
worker2 Ready <none> 2d16h v1.32.7

The description of the node provide additional information

$ kubectl describe node worker1
...
Events:
 Type Reason Age From Message
 ---- ------ ---- ---- -------
 Normal RegisteredNode 57m node-controller Node worker1 event: Registered Node worker1 in Controller
 Normal NodeNotReady 25m node-controller Node worker1 status is now: NodeNotReady
 Normal Starting 24m kubelet Starting kubelet.
 Normal NodeReady 24m kubelet Node worker1 status is now: NodeReady
 Normal NodeAllocatableEnforced 24m kubelet Updated Node Allocatable limit across pods
 Normal NodeHasSufficientMemory 24m (x2 over 24m) kubelet Node worker1 status is now: NodeHasSufficientMemory
 Normal NodeHasNoDiskPressure 24m (x2 over 24m) kubelet Node worker1 status is now: NodeHasNoDiskPressure
 Normal NodeHasSufficientPID 24m (x2 over 24m) kubelet Node worker1 status is now: NodeHasSufficientPID
 Normal RegisteredNode 22m node-controller Node worker1 event: Registered Node worker1 in Controller
 Normal RegisteredNode 96s node-controller Node worker1 event: Registered Node worker1 in Controller
 Normal NodeNotReady 26s node-controller Node worker1 status is now: NodeNotReady

The Node in NodeNotReady status may indicate kubelet is having trouble. We have the confirmation checking the kubelet status with systemctl on this specific Node.

Solution - Ch3

Mon, 01 Jan 0001 00:00:00 +0000

Test

Let’s create a new Pod and expose it with a ClusterIP Service

kubectl run nginx --image=nginx:1.20 --port 80 --expose

Let’s new get an interactive shell in an Alpine based Pod

kubectl run -ti --rm debug --image=alpine -- sh

We cannot reach the nginx Pod from the debug one:

/ # wget http://nginx
wget: bad address 'nginx'

Going one step further we can see the name resolution is not working fine:

/ # nslookup nginx
;; connection timed out; no servers could be reached

Checking the cluster’s internal DNS

kubectl get deploy -n kube-system
NAME READY UP-TO-DATE AVAILABLE AGE
coredns 0/0 0 0 2d17h

Seems like there is no replica running for the dns (should be 2 by default)

Solution - Ch4

Mon, 01 Jan 0001 00:00:00 +0000

Test

List the resources in app2

$ kubectl get po,svc -n app2
NAME READY STATUS RESTARTS AGE
pod/nginx 1/1 Running 0 8s

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/nginx NodePort 10.106.164.238 <none> 80:30000/TCP 8s

From a worker node, try to reach the nginx Pod

$ curl localhost:30000
curl: (7) Failed to connect to localhost port 30000: Connection refused

Check the service

kubectl describe svc nginx -n app2
Name: nginx
Namespace: app2
Labels: <none>
Annotations: <none>
Selector: app=nginx
Type: NodePort
IP Family Policy: SingleStack
IP Families: IPv4
IP: 10.106.164.238
IPs: 10.106.164.238
Port: <unset> 80/TCP
TargetPort: 80/TCP
NodePort: <unset> 30000/TCP
Endpoints: <none>
Session Affinity: None
External Traffic Policy: Cluster
Events: <none>

The list of Endpoints is empty, that is surely a problem. The Service’s selector is app: nginx, let’s see the content of the Pod’s labels.

Solution - Ch5

Mon, 01 Jan 0001 00:00:00 +0000

Test

The single replica is not running

kubectl get deploy,po -n app1
NAME READY UP-TO-DATE AVAILABLE AGE
deployment.apps/nginx 0/1 1 0 79m

NAME READY STATUS RESTARTS AGE
pod/nginx-7b4b5bbf6f-dth6d 0/1 ImagePullBackOff 0 79m

The description of the nginx Pod gives additional information

kubectl describe po pod/nginx-7b4b5bbf6f-dth6d
...
Events:
 Type Reason Age From Message
 ---- ------ ---- ---- -------
 Normal BackOff 16s (x351 over 80m) kubelet Back-off pulling image "ngnix:1.26"

Fix it

Edit the Deployment and replace the image name ngnix:1.26 with nginx:1.26, a little typo can have big consequences :)

Solution - Ch6

Mon, 01 Jan 0001 00:00:00 +0000

Test

Try to create a pod:

kubectl run ghost --image=ghost:4

Verify it is running:

$ kubectl get po
NAME READY STATUS RESTARTS AGE
ghost 0/1 Pending 0 10s

There is definitely something wrong as the pod remains in pending status.

$ kubectl describe po ghost
...
Events:
 Type Reason Age From Message
 ---- ------ ---- ---- -------
 Warning FailedScheduling 4s (x2 over 72s) default-scheduler 0/3 nodes are available: 3 node(s) had taint {app: secure}, that the pod didn't tolerate.

It seems the 3 nodes have a taint that prevents the pod from being scheduled. We can see there are 2 taints on the master:

Solution - Ch7

Mon, 01 Jan 0001 00:00:00 +0000

Observe the behavior of the pod you will notice the pod is automatically restarted after a few tens of seconds:

$ kubectl get po -w
NAME READY STATUS RESTARTS AGE
demo 1/1 Running 0 2s
demo 1/1 Running 1 (1s ago) 76s

Going a little deeper in the details, we understand this is due to the liveness probe failing:

$ kubectl describe po demo
...
Events:
 Type Reason Age From Message
 ---- ------ ---- ---- -------
 Normal Scheduled 2m8s default-scheduler Successfully assigned default/demo to worker1
 Normal Pulled 2m7s kubelet Successfully pulled image "k8s.gcr.io/busybox" in 578.053377ms
 Normal Pulling 53s (x2 over 2m7s) kubelet Pulling image "k8s.gcr.io/busybox"
 Normal Created 52s (x2 over 2m6s) kubelet Created container busybox
 Normal Started 52s (x2 over 2m6s) kubelet Started container busybox
 Normal Pulled 52s kubelet Successfully pulled image "k8s.gcr.io/busybox" in 512.064103ms
 Warning Unhealthy 8s (x6 over 93s) kubelet Liveness probe failed: cat: can't open '/tmp/healthy': No such file or directory
 Normal Killing 8s (x2 over 83s) kubelet Container busybox failed liveness probe, will be restarted

If we check the pod’s specification, we can see the liveness probe checks the existence of a file:

Solution - Drain

Mon, 01 Jan 0001 00:00:00 +0000

Create a Deployment with 6 replicas of Pods based on the nginx:1.20 image

k create deploy www --image=nginx:1.20 --replicas=4

Where are the pods scheduled ?

The pods are splitted between worker1 and worker2 (because master node has a NoScheduled taint that the pods do not tolerate)

k get po -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
www-644dfdf68b-6mk2w 1/1 Running 0 33s 10.38.0.1 worker2 <none> <none>
www-644dfdf68b-crdjl 1/1 Running 0 33s 10.32.0.6 worker1 <none> <none>
www-644dfdf68b-nhm7b 1/1 Running 0 33s 10.32.0.2 worker1 <none> <none>
www-644dfdf68b-tsw84 1/1 Running 0 33s 10.38.0.5 worker2 <none> <none>

Drain the worker1 node. What happened ?

k drain worker1 --ignore-daemonsets

The application pods have been evicted from worker1 and are now all running on worker2

Solution - Metrics

Mon, 01 Jan 0001 00:00:00 +0000

Install the metrics server (https://github.com/kubernetes-sigs/metrics-server)

k apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

Verify it’s not running correctly

Trying to get the Nodes or Pods metrics should return an error

k top node
Error from server (ServiceUnavailable): the server is currently unable to handle the request (get nodes.metrics.k8s.io)

k top pod
Error from server (ServiceUnavailable): the server is currently unable to handle the request (get pods.metrics.k8s.io)

Checking the logs of the metrics-server pod will provide additional details

Solution - Nodes

Mon, 01 Jan 0001 00:00:00 +0000

Create a Deployment named web-app with 6 replicas using nginx:1.26 image

kubectl create deployment web-app --image=nginx:1.26 --replicas=6

Create a DaemonSet named monitoring using nginx:alpine image

kubectl create -f - <<EOF
apiVersion: apps/v1
kind: DaemonSet
metadata:
 name: monitoring
spec:
 selector:
 matchLabels:
 app: monitoring
 template:
 metadata:
 labels:
 app: monitoring
 spec:
 containers:
 - name: monitoring
 image: nginx:alpine
 ports:
 - containerPort: 80
EOF

Check how Pods are distributed across all Nodes

kubectl get pods -o wide

You should see Pods are distributed across worker Nodes, and one monitoring Pod per Node.