Giter VIP home page Giter VIP logo

kub-que-pattern's Introduction

kub-que-pattern

Core Concepts (13%)

Creating a Pod and Inspecting it

  1. Create the namespace ckad-prep.
  2. In the namespace ckad-prep create a new Pod named mypod with the image nginx:2.3.5. Expose the port 80.
  3. Identify the issue with creating the container. Write down the root cause of issue in a file named pod-error.txt.
  4. Change the image of the Pod to nginx:1.15.12.
  5. List the Pod and ensure that the container is running.
  6. Log into the container and run the ls command. Write down the output. Log out of the container.
  7. Retrieve the IP address of the Pod mypod.
  8. Run a temporary Pod using the image busybox, shell into it and run a wget command against the nginx Pod using port 80.
  9. Render the logs of Pod mypod.
  10. Delete the Pod and the namespace.

Configuration (18%)

Configuring a Pod to Use a ConfigMap

  1. Create a new file named config.txt with the following environment variables as key/value pairs on each line.
  • DB_URL equates to localhost:3306
  • DB_USERNAME equates to postgres
  1. Create a new ConfigMap named db-config from that file.
  2. Create a Pod named backend that uses the environment variables from the ConfigMap and runs the container with the image nginx.
  3. Shell into the Pod and print out the created environment variables. You should find DB_URL and DB_USERNAME with their appropriate values.

Configuring a Pod to Use a Secret

  1. Create a new Secret named db-credentials with the key/value pair db-password=passwd.
  2. Create a Pod named backend that defines uses the Secret as environment variable named DB_PASSWORD and runs the container with the image nginx.
  3. Shell into the Pod and print out the created environment variables. You should find DB_PASSWORD variable.

Creating a Security Context for a Pod

  1. Create a Pod named secured that uses the image nginx for a single container. Mount an emptyDir volume to the directory /data/app.
  2. Files created on the volume should use the filesystem group ID 3000.
  3. Get a shell to the running container and create a new file named logs.txt in the directory /data/app. List the contents of the directory and write them down.

Defining a Pod’s Resource Requirements

Create a resource quota named apps under the namespace rq-demo using the following YAML definition in the file rq.yaml.

apiVersion: v1
kind: ResourceQuota
metadata:
  name: app
spec:
  hard:
    pods: "2"
    requests.cpu: "2"
    requests.memory: 500m
  1. Create a new Pod that exceeds the limits of the resource quota requirements. Write down the error message.
  2. Change the request limits to fulfill the requirements to ensure that the Pod could be created successfully. Write down the output of the command that renders the used amount of resources for the namespace.

Multi-Container Pods (10%)

Implementing the Adapter Pattern

The adapter pattern helps with providing a simplified, homogenized view of an application running within a container. For example, we could stand up another container that unifies the log output of the application container. As a result, other monitoring tools can rely on a standardized view of the log output without having to transform it into an expected format.

  1. Create a new Pod in a YAML file named adapter.yaml. The Pod declares two containers. The container app uses the image busybox and runs the command while true; do echo "$(date) | $(du -sh ~)" >> /var/logs/diskspace.txt; sleep 5; done;. The adapter container transformer uses the image busybox and runs the command sleep 20; while true; do while read LINE; do echo "$LINE" | cut -f2 -d"|" >> $(date +%Y-%m-%d-%H-%M-%S)-transformed.txt; done < /var/logs/diskspace.txt; sleep 20; done; to strip the log output off the date for later consumption my a monitoring tool. Be aware that the logic does not handle corner cases (e.g. automatically deleting old entries) and would look different in production systems.
  2. Before creating the Pod, define an emptyDir volume. Mount the volume in both containers with the path /var/logs.
  3. Create the Pod, log into the container transformer. The current directory should continuously write a new file every 20 seconds.

Observability (18%)

Defining a Pod’s Readiness and Liveness Probe

  1. Create a new Pod named hello with the image bonomat/nodejs-hello-world that exposes the port 3000. Provide the name nodejs-port for the container port.
  2. Add a Readiness Probe that checks the URL path / on the port referenced with the name nodejs-port after a 2 seconds delay. You do not have to define the period interval.
  3. Add a Liveness Probe that verifies that the app is up and running every 8 seconds by checking the URL path / on the port referenced with the name nodejs-port. The probe should start with a 5 seconds delay.
  4. Shell into container and curl localhost:3000. Write down the output. Exit the container.
  5. Retrieve the logs from the container. Write down the output.

Fixing a Misconfigured Pod

  1. Create a new Pod with the following YAML.
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: failing-pod
  name: failing-pod
spec:
  containers:
  - args:
    - /bin/sh
    - -c
    - while true; do echo $(date) >> ~/tmp/curr-date.txt; sleep
      5; done;
    image: busybox
    name: failing-pod
    resources: {}
  dnsPolicy: ClusterFirst
  restartPolicy: Never
status: {}
  1. Check the Pod's status. Do you see any issue?
  2. Follow the logs of the running container and identify an issue.
  3. Fix the issue by shelling into the container. After resolving the issue the current date should be written to a file. Render the output.

Pod Design (20%)

Defining and Querying Labels and Annotations

  1. Create three different Pods with the names frontend, backend and database that use the image nginx.
  2. Declare labels for those Pods as follows:
  • frontend: env=prod, team=shiny
  • backend: env=prod, team=legacy, app=v1.2.4
  • database: env=prod, team=storage
  1. Declare annotations for those Pods as follows:
  • frontend: contact=John Doe, commit=2d3mg3
  • backend: contact=Mary Harris
  1. Render the list of all Pods and their labels.
  2. Use label selectors on the command line to query for all production Pods that belong to the teams shiny and legacy.
  3. Remove the label env from the backend Pod and rerun the selection.
  4. Render the surrounding 3 lines of YAML of all Pods that have annotations.

Performing Rolling Updates for a Deployment

  1. Create a Deployment named deploy with 3 replicas. The Pods should use the nginx image and the name nginx. The Deployment uses the label tier=backend. The Pods should use the label app=v1.
  2. List the Deployment and ensure that the correct number of replicas is running.
  3. Update the image to nginx:latest.
  4. Verify that the change has been rolled out to all replicas.
  5. Scale the Deployment to 5 replicas.
  6. Have a look at the Deployment rollout history.
  7. Revert the Deployment to revision 1.
  8. Ensure that the Pods use the image nginx.

Creating a Scheduled Container Operation

  1. Create a CronJob named current-date that runs every minute and executes the shell command echo "Current date: $(date)".
  2. Watch the jobs as they are being scheduled.
  3. Identify one of the Pods that ran the CronJob and render the logs.
  4. Determine the number of successful executions the CronJob will keep in its history.
  5. Delete the Job.

Services & Networking (13%)

Routing Traffic to Pods from Inside and Outside of a Cluster

  1. Create a deployment named myapp that creates 2 replicas for Pods with the image nginx. Expose the container port 80.
  2. Expose the Pods so that requests can be made against the service from inside of the cluster.
  3. Create a temporary Pods using the image busybox and run a wget command against the IP of the service.
  4. Change the service type so that the Pods can be reached from outside of the cluster.
  5. Run a wget command against the service from outside of the cluster.
  6. (Optional) Can you expose the Pods as a service without a deployment?

Restricting Access to and from a Pod

Let's assume we are working on an application stack that defines three different layers: a frontend, a backend and a database. Each of the layers runs in a Pod. You can find the definition in the YAML file app-stack.yaml. The application needs to run in the namespace app-stack.

kind: Pod
apiVersion: v1
metadata:
  name: frontend
  namespace: app-stack
  labels:
    app: todo
    tier: frontend
spec:
  containers:
    - name: frontend
      image: nginx

---

kind: Pod
apiVersion: v1
metadata:
  name: backend
  namespace: app-stack
  labels:
    app: todo
    tier: backend
spec:
  containers:
    - name: backend
      image: nginx

---

kind: Pod
apiVersion: v1
metadata:
  name: database
  namespace: app-stack
  labels:
    app: todo
    tier: database
spec:
  containers:
    - name: database
      image: mysql
      env:
      - name: MYSQL_ROOT_PASSWORD
        value: example
  1. Create the required namespace.
  2. Copy the Pod definition to the file app-stack.yaml and create all three Pods. Notice that the namespace has already been defined in the YAML definition.
  3. Create a network policy in the YAML file app-stack-network-policy.yaml.
  4. The network policy should allow incoming traffic from the backend to the database but disallow incoming traffic from the frontend.
  5. Incoming traffic to the database should only be allowed on TCP port 3306 and no other port.

State Persistence (8%)

Defining and Mounting a PersistentVolume

  1. Create a Persistent Volume named pv, access mode ReadWriteMany, storage class name shared, 512MB of storage capacity and the host path /data/config.
  2. Create a Persistent Volume Claim named pvc that requests the Persistent Volume in step 1. The claim should request 256MB. Ensure that the Persistent Volume Claim is properly bound after its creation.
  3. Mount the Persistent Volume Claim from a new Pod named app with the path /var/app/config. The Pod uses the image nginx.
  4. Check the events of the Pod after starting it to ensure that the Persistent Volume was mounted properly.

kub-que-pattern's People

Contributors

raji4ac avatar

Watchers

 avatar

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.