├── limits.yaml ├── Readme.md ├── RevisionTopics ├── Part-3-Multi-Container-Pods.md ├── Part-6-Services-And-Networking.md ├── Part-5-Pod-Design.md ├── Part-4-Observability.md ├── Part-1-Core-Concepts.md ├── Part-2-Configuration.md └── Images │ ├── Multi.svg │ └── pods.svg └── LICENSE /limits.yaml: -------------------------------------------------------------------------------- 1 | apiVersion: v1 2 | kind: Pod 3 | metadata: 4 | labels: 5 | run: nginx 6 | name: nginx-limits 7 | spec: 8 | containers: 9 | - image: nginx 10 | name: nginx 11 | resources: 12 | limits: 13 | cpu: 1 14 | memory: "200Mi" 15 | requests: 16 | cpu: 0.5 17 | memory: "100Mi" 18 | -------------------------------------------------------------------------------- /Readme.md: -------------------------------------------------------------------------------- 1 | # CKA-Study Guide 2 | The following guide is based on the Certified Kubernetes Application Developer Curriculum 1.17 and consists of the following sections: 3 | 4 | ### [Revision Topics](https://github.com/David-VTUK/CKAD-StudyGuide/tree/master/RevisionTopics) 5 | 6 | Notes from revising the topics listed in the curriculum, grouped to correlate to the various sections listed in the curriculum. 7 | 8 | ### [Lab Guide](https://github.com/David-VTUK/CKAD-StudyGuide/tree/master/LabGuide) 9 | 10 | To complement the revision topics, these lab guides are designed to exercise the topics learnt from the corresponding revision topics sections. 11 | 12 | ### [Lab Guide - Answers](https://github.com/David-VTUK/CKAD-StudyGuide/tree/master/LabGuideAnswers) 13 | 14 | These list potential solutions to the tasks listed in the respective lab exercises. **Note:** these provide **one** way of approaching the exercises. There are a number of ways to achieve the same goal. 15 | 16 | 17 | ### Lab Environments 18 | 19 | https://kubernetes.io/docs/setup/learning-environment/minikube/ 20 | 21 | ### Contact 22 | 23 | Twitter = @VT_UK 24 | -------------------------------------------------------------------------------- /RevisionTopics/Part-3-Multi-Container-Pods.md: -------------------------------------------------------------------------------- 1 | # Understand Multi-Container Pod design patterns 2 | 3 | Part 1 documents how Pod manifests can be configured to include multiple containers and also share volumes between them, but as part of a Pod design, identifying **when** to leverage multi container pods. 4 | 5 | # How Multi-Container Pods communicate 6 | 7 | Pods share a virtual network adapter in order for the containers within to communicate with anything outside the Pod boundary. Additionally, containers within a Pod can communicate over `localhost`. 8 | 9 |  10 | 11 | Sharing storage between containers in a Pod is covered in part 1. 12 | 13 | # Deciding between single or multi container Pods 14 | 15 | Deciding when or when not to use multi container Pods essentially boils down determining how **tightly coupled** the workloads are. 16 | 17 | # Sidecar 18 | 19 | Typically used as a "helper" container for the "main" container. Ie: 20 | 21 | * File sync services/watchers 22 | * Logging agents 23 | * Traffic manipulation (ie Service Mesh) 24 | 25 | By offloading these responsibilities to a sidecar container, it keeps the "main" container lean. 26 | 27 | # Ambassador 28 | 29 | Ambassador containers, unlike its Sidecar counterpart, are usually in the data path and proxies connections to external services and is typically used for : 30 | 31 | * Proxying connections to different environments (ie prod/test/dev) based on Pod spec/configuration 32 | 33 | # Adapter 34 | 35 | Adaptor containers typically manipulate / transform output of the main container as required. For example: 36 | 37 | * Transforms output generated by the main container to fit a certain standard. For example, as dictated by a monitoring/logging system. 38 | 39 | -------------------------------------------------------------------------------- /RevisionTopics/Part-6-Services-And-Networking.md: -------------------------------------------------------------------------------- 1 | # Understand Services 2 | 3 | Pods are ephemeral. Therefore placing these behind a service which provides a stable, static entrypoint is a fundamental use of the kubernetes service object. To reiterate, services take the form of the following: 4 | 5 | * ClusterIP - Internal only 6 | * LoadBalancer - External, requires cloud provider to provide one 7 | * NodePort - External, requires access the nodes directly 8 | * Ingress resource - L7 An Ingress can be configured to give services externally-reachable URLs, load balance traffic, terminate SSL, and offer name based virtual hosting. An Ingress controller is responsible for fulfilling the Ingress, usually with a loadbalancer, though it may also configure your edge router or additional frontends to help handle the traffic. 9 | 10 | An example of deploying a Load Balancer: 11 | ``` 12 | apiVersion: v1 13 | kind: Service 14 | metadata: 15 | name: my-nginx 16 | labels: 17 | run: my-nginx 18 | spec: 19 | type: LoadBalancer 20 | ports: 21 | - port: 80 22 | protocol: TCP 23 | name: http 24 | targetPort: 80 25 | selector: 26 | run: my-nginx 27 | ``` 28 | 29 | * Port- The port the LB itself will listen on 30 | 31 | * Target port - The port on the pods to forward connections to 32 | 33 | * Selector - The pods that we want to load balance to. In the above example pods matching the `run: my-nginx` label. 34 | 35 | # Demonstrate Basic Understanding of `NetworkPolicies` 36 | 37 | These determine if pods communicate with each other. By default this is left completely open. Think of this as firewall rules. We can apply network policies by: 38 | 39 | * Pod selectors (labels) 40 | * Namespace selectors 41 | * CIDR blocks ranges 42 | 43 | If we were to run a nginx container and curl to it from a pod, it works as expected. 44 | 45 | ``` 46 | /home # curl 10.10.57.2 47 | 48 | 49 |
50 |