├── LICENSE ├── README.md └── objectives ├── cluster_arch.md └── overview.md /LICENSE: -------------------------------------------------------------------------------- 1 | MIT License 2 | 3 | Copyright (c) 2020 Ned Bellavance 4 | 5 | Permission is hereby granted, free of charge, to any person obtaining a copy 6 | of this software and associated documentation files (the "Software"), to deal 7 | in the Software without restriction, including without limitation the rights 8 | to use, copy, modify, merge, publish, distribute, sublicense, and/or sell 9 | copies of the Software, and to permit persons to whom the Software is 10 | furnished to do so, subject to the following conditions: 11 | 12 | The above copyright notice and this permission notice shall be included in all 13 | copies or substantial portions of the Software. 14 | 15 | THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR 16 | IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, 17 | FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE 18 | AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER 19 | LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, 20 | OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE 21 | SOFTWARE. 22 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # CKA-Study-Guide 2 | This is my (Ned Bellavance) study guide for the Certified Kubernetes Administrator exam. In the guide I plan to include relevant study materials, the exam objectives, and code examples. 3 | 4 | ## How to use this guide 5 | 6 | I'm just starting to write the guide, so honestly I'm not sure how it will be used. My best guess is to look at my notes for each objective and check out the code examples. 7 | 8 | ## Pre-requisites 9 | Personally I plan to use a combination of Docker Desktop, minikube, and Azure Kubernetes Service to work on the code exercises. I may also try *Kubernetes the Hard Way* except on Microsoft Azure to save money. I've got `kubectl` installed, along with helm. And I am going to use Windows Subsystem for Linux v2 for the exercises. We'll see how it goes. 10 | 11 | ## Branching 12 | My plan is to create a branch for each objective and merge the branches into `main` when I feel each is completed. Please don't commit to main. 13 | -------------------------------------------------------------------------------- /objectives/cluster_arch.md: -------------------------------------------------------------------------------- 1 | # Cluster architecture, installation, and configuration 2 | 3 | The following objectives live under this domain: 4 | 5 | * Manage RBAC 6 | * Use Kubeadm to install a basic cluster 7 | * Manage a highly-available Kubernetes cluster 8 | * Provision underlying infrastructure to deploy a Kubernetes cluster 9 | * Perform a version upgrade on a Kubernetes cluster using Kubeadm 10 | * Implement etcd backup and restore 11 | 12 | ## Manage RBAC 13 | Managing RBAC means understanding what the RBAC components are and how they fit together. Right now I know that there are roles, roleBindings, clusterRoles, clusterRoleBindings, and serviceAccounts. Those are the objects I know about. 14 | 15 | When a user or pod (service account) tries to use the Kubernetes API, they have to go through three steps: Authentication (AuthN), Authorization (AuthZ), and Admission Control. 16 | 17 | **Authentication** is configured through an *Authenticator module* running on the API server. This doesn't seem to be in scope with the objective, but it's good to know. You can have multiple authentication modules running and they could use items like certificates, passwords, JWTs, etc. There is no `User` object or stored usernames, which is hella-weird, but OK. You do you K8s. 18 | 19 | **Authorization** is where we start getting into the world of RBAC. When submitting a request, you need to include the username, requested action, and object affected by the action. K8s will check policies associated with you and determine if there is a policy allowing the action. There are different authorization modules, including ABAC, RBAC, and Webhook. The focus for the exam is on RBAC. 20 | 21 | **Admission control** is handled by modules that can either modify or reject a request. Admission controllers do not act on read requests. Their purpose is mostly to check on data about the object being modified, and then make a decision or alteration to the original request. Requests can go through multiple AC modules, and if any one rejects the request, processing stops. 22 | 23 | ### RBAC notes 24 | 25 | The API group that RBAC uses is `rbac.authorization.k8s.io`. The API server needs to be started with the `--authorization-mode=RBAC` flag and value to enable RBAC. 26 | 27 | Woo hoo! I was right. There are four API objects for RBAC: 28 | 29 | * Role - sets permission in a namespace 30 | * RoleBinding - grants permissions to a list of *subjects* 31 | * ClusterRole - sets permissions in a non-namespace context 32 | * ClusterRoleBinding - grants permissions to a list of *subjects* 33 | 34 | There are also three types of subjects. 35 | 36 | * Users - are defined using a string and must map to an object in an authentication module 37 | * Groups - are defined using a string and must map to an object in an authentication module 38 | * ServiceAccounts - are defined within Kubernetes and prefixed with `system:serviceaccount:` 39 | 40 | The only restriction on naming groups and users is that the prefix `system` is reserved for Kubernetes subjects. So don't try it! Things could get real wonky. ServiceAccounts can belong to groups, which uses the prefix `system:serviceaccounts:` (note the plural). 41 | 42 | #### Roles 43 | 44 | What's in this crazy role thing? Let's start with a manifest: 45 | 46 | ```yaml 47 | apiVersion: rbac.authorization.k8s.io/v1 48 | kind: Role 49 | metadata: 50 | namespace: tacos 51 | name: taco-pod 52 | rules: 53 | - apiGroups: [""] 54 | resources: ["pods"] 55 | resourceNames: [""] 56 | verbs: ["get","watch","list"] 57 | ``` 58 | 59 | Let's get some more context around the fields in the manifest, especially `apiGroups`, `resources`, and `verbs`. 60 | 61 | * **apiGroups**: These are REST paths to different [API groupings](https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#-strong-api-groups-strong-). An example would be `extension`. 62 | * **resources**: This can be any defined resource type, including custom resources. 63 | * **resourceNames**: You can directly reference a named resource, but it cannot apply to `create` since the resource does not yet exist. 64 | * **verbs**: I think these are related to API verbs, but I need to find a comprehensive list *TODO* 65 | 66 | Commands for dealing with roles: 67 | * `kubectl create role`: example - `kubectl create role taco-pods --verb=get --verb=list --verb=watch --resource=pods --namespace=tacos` 68 | 69 | You can reference sub-resources by giving the path from the main resource, for instance `pods/status`. That could be useful for giving a service permissions to check the status of a pod, but not other aspects. 70 | 71 | #### Role Binding 72 | 73 | The next item in RBAC has to be the RoleBinding, which connects the role to an identity. Once again, let's take a look at a sample manifest to get an idea of what's going on inside the RoleBinding. 74 | 75 | ```yaml 76 | apiVersion: rbac.authorization.k8s.io/v1 77 | kind: RoleBinding 78 | metadata: 79 | name: taco-pod-binding-ned 80 | namespace: tacos 81 | subjects: 82 | # You can specify more than one "subject" 83 | - kind: User 84 | name: ned # "name" is case sensitive 85 | apiGroup: rbac.authorization.k8s.io 86 | roleRef: 87 | # "roleRef" specifies the binding to a Role / ClusterRole 88 | kind: Role #this must be Role or ClusterRole 89 | name: taco-pod # this must match the name of the Role or ClusterRole you wish to bind to 90 | apiGroup: rbac.authorization.k8s.io 91 | ``` 92 | 93 | Alright, let's break things down a bit. 94 | 95 | * **kind** is obvious and the metadata specifies where this resource should be created. RoleBindings are namespaced, so we have to give it a name and a namespace. 96 | * **subjects** looks like you can specify one or more subjects of different kinds. What kinds are supported? Users, groups, and service accounts. 97 | * **roleRef** refers to the role you want to bind. Turns out this can be either a Role or a ClusterRole. If you use a ClusterRole, it will only apply to the namespace defined in the metadata. 98 | 99 | Commands for working with RoleBindings: 100 | * `kubectl create rolebinding`: example - `kubectl create rolebinding taco-pod-binding-ned --role=taco-pod --user=ned --namespace tacos` 101 | 102 | #### ClusterRole 103 | 104 | A ClusterRole is like the role we looked at before, but it is not restricted to a namespace. You can use a ClusterRole to define permissions on resources that are not namespaced, or provide blanket permissions across an entire cluster and all namespaces within. The classic example is the `cluster-admin`, which can do basically anything when bound to a user. 105 | 106 | What does a manifest for a ClusterRole look like? (Hint: very similar to a Role) 107 | 108 | ```yaml 109 | apiVersion: rbac.authorization.k8s.io/v1 110 | kind: ClusterRole 111 | metadata: 112 | # "namespace" omitted since ClusterRoles are not namespaced 113 | name: secret-reader 114 | rules: 115 | - apiGroups: [""] 116 | # at the HTTP level, the name of the resource for accessing Secret 117 | # objects is "secrets" 118 | resources: ["secrets"] 119 | verbs: ["get", "watch", "list"] 120 | ``` 121 | 122 | The role above would be able to monitor and access Kubernetes secrets across all namespaces (secrets are a namespaced resource). We could also add a cluster resource like a node, which is not namespaced. The individual fields are virtual identical to the Role, with the exception being the lack of a namespace in the metadata area. 123 | 124 | You would create a ClusterRole imperatively by using: 125 | * `kubectl create clusterrole`: example - `kubectl create clusterrole secret-reader --resource=secrets --verb=get,watch,list` 126 | 127 | ##### ClusterRole Aggregation 128 | 129 | ClusterRoles can also aggregate the settings of one or more ClusterRoles into a single role. You can define permissions on resources separately and then mix and match a ClusterRole you need. A primary use case would be granting permissions on Custom Resource Definitions. When a new CRD is being defined, you could also define a ClusterRole and add it to existing ClusterRoles, without altering those ClusterRoles. 130 | 131 | Kubernetes uses aggregation for some of the user-facing roles that are created by default. The aggregation setting uses labels to decide which ClusterRoles to include in the aggregated ClusterRole. Let's take a look at the `admin` ClusterRole that is created by default. 132 | 133 | ```yaml 134 | apiVersion: rbac.authorization.k8s.io/v1 135 | kind: ClusterRole 136 | metadata: 137 | name: admin 138 | aggregationRule: 139 | clusterRoleSelectors: 140 | - matchLabels: 141 | rbac.authorization.k8s.io/aggregate-to-admin: "true" 142 | rules: [] 143 | ``` 144 | 145 | Any ClusterRole created that has the label `rbac.authorization.k8s.io/aggregate-to-admin` set to `"true"` will be included in this aggregate ClusterRole. So if I add a new CRD called `burrito` and want to allow someone with the `admin` ClusterRole bound to administer `burrito` customer resources, I can create the following ClusterRole: 146 | 147 | ```yaml 148 | kind: ClusterRole 149 | apiVersion: rbac.authorization.k8s.io/v1 150 | metadata: 151 | name: aggregate-burrito-admin 152 | labels: 153 | # Add these permissions to the "view" default role. 154 | rbac.authorization.k8s.io/aggregate-to-admin: "true" 155 | rules: 156 | - apiGroups: [""] 157 | resources: ["burritos"] 158 | verbs: ["create", "delete", "patch","update","get","list","watch"] 159 | ``` 160 | 161 | You could even create a ClusterRole with view permissions and another with modify permissions and label both for inclusion in the admin ClusterRole. This is a pretty cool tool! There is nothing like this for regular rules. 162 | 163 | #### ClusterRoleBinding 164 | 165 | Just like we saw with the RoleBinding, you can bind an identity (user, group, or service account) to a ClusterRole. Once again, since there is no namespacing for ClusterRoles, you don't specify one in the configuration. 166 | 167 | Here's an example manifest: 168 | 169 | ```yaml 170 | apiVersion: rbac.authorization.k8s.io/v1 171 | kind: ClusterRoleBinding 172 | metadata: 173 | name: read-secrets-global-ned 174 | subjects: 175 | - kind: User 176 | name: ned # Name is case sensitive 177 | apiGroup: rbac.authorization.k8s.io 178 | roleRef: 179 | kind: ClusterRole 180 | name: secret-reader 181 | apiGroup: rbac.authorization.k8s.io 182 | ``` 183 | 184 | The spec is almost the same as the RoleBinding, so no need to get into much detail here. You could accomplish the same goal with the following command: 185 | * `kubectl create clusterrolebinding`: example - `kubectl create clusterrolebinding read-secrets-global-ned --clusterrole=secret-reader --user=ned` 186 | 187 | Excellent. What else do I need to know about RBAC? Nothing, right? WRONG! 188 | 189 | #### Default roles 190 | 191 | Kubernetes creates a set of default roles and role-bindings when you set it up. The definition of the default roles are refreshes when Kubernetes starts up, and will overwrite any changes or modifications you have made. Sooooo, maybe don't edit those roles. The process is called auto-reconciliation, and it not only helps to keep settings current, it also updates ClusterRoles and ClusterRoleBindings when you upgrade or patch your cluster. 192 | 193 | If you look at one of the default roles, you're going to see this annotation: `rbac.authorization.kubernetes.io/autoupdate: "true"`. You can alter the value to `"false"` and Kubernetes will stop auto-reconciling the role. **DANGER** - yeah, you probably shouldn't do this unless you're 100% sure, because you can break your cluster next time it boots. 194 | 195 | There are five categories of roles to remember: 196 | 197 | * API discovery - Default role bindings authorize unauthenticated and authenticated users to read API information that is deemed safe to be publicly accessible. These roles will have the `system` prefix associated with them, like `system:discovery`. 198 | * User-facing - These roles do not have the `system` prefix and are intended to be associated with users and bound at the cluster or namespace level. Many of these ClusterRoles use aggregation, such as the `admin` role we looked at before. 199 | * Core component - These roles do begin with the `system` prefix and they are for the core components of Kubernetes: kube-scheduler, volume-scheduler, kube-controller-manager, node, and node-proxier. 200 | * Other component - These roles begin with the `system` prefix and honestly, the "Other" labeling seems a bit arbitrary. I'm sure there's a good reason they aren't part of the core, but I can't discern one. 201 | * Built-in controllers - The controller manager will bind these roles to the service account of controllers running on Kubernetes, or to itself if those controllers are not using a service account. All of these roles are prefixed with `system:controller:`. 202 | 203 | ## Use Kubeadm to install a basic cluster 204 | 205 | ## Manage a highly-available Kubernetes cluster 206 | 207 | ## Provision underlying infrastructure to deploy a Kubernetes cluster 208 | 209 | ## Perform a version upgrade on a Kubernetes cluster using Kubeadm 210 | 211 | ## Implement etcd backup and restore -------------------------------------------------------------------------------- /objectives/overview.md: -------------------------------------------------------------------------------- 1 | # Overview 2 | 3 | The exam has five weighted domains that cover different topics. They are broken out as shown below: 4 | 5 | | Domain | Weight | 6 | |--------|--------| 7 | | Cluster architecture, installation, and configuration | 25% | 8 | | Workloads and scheduling | 15% | 9 | | Services and networking | 20% | 10 | | Storage | 10% | 11 | | Troubleshooting | 30% | 12 | 13 | The exam environment is current running v1.19. For any learning that I do, I should use a v1.19 environment. 14 | 15 | You can use the following resources during the exam, so study them now! 16 | 17 | * Kubernetes docs: https://kubernetes.io/docs/ 18 | * Kubernetes GitHub: https://github.com/kubernetes/ 19 | * Kubernetes Blog: https://kubernetes.io/blog/ 20 | 21 | Don't try to access any other sites during the exam! (That means no checking Twitter for the latest update from your favorite K8s superstar.) 22 | 23 | ## Curriculum 24 | 25 | The current curriculum is hosted on [GitHub](https://github.com/cncf/curriculum). There are PDFs for each exam type. The CKA curriculum is broken down by domain. 26 | 27 | ### Cluster architecture, installation, and configuration 28 | 29 | The following objectives live under this domain: 30 | 31 | * Manage RBAC 32 | * Use Kubeadm to install a basic cluster 33 | * Manage a highly-available Kubernetes cluster 34 | * Provision underlying infrastructure to deploy a Kubernetes cluster 35 | * Perform a version upgrade on a Kubernetes cluster using Kubeadm 36 | * Implement etcd backup and restore 37 | 38 | ### Workloads and scheduling 39 | 40 | The following objectives live under this domain: 41 | 42 | * Understand deployments and how to perform rolling update and rollbacks 43 | * Use ConfigMaps and Secrets to configure applications 44 | * Know how to scale applications 45 | * Understand primitives used to create robust, self-healing, application deployments 46 | * Understand how resource limits can affect Pod scheduling 47 | * Awareness of manifest management and common templating tools 48 | 49 | ### Services and networking 50 | 51 | * Understand host networking configuration on the cluster nodes 52 | * Understand connectivity between Pods 53 | * Understand ClusterIP, NodePort, LoadBalancer service types and endpoints 54 | * Know how to use Ingress controllers and Ingress resources 55 | * Know how to configure and use CoreDNS 56 | * Choose an appropriate container network interface plugin 57 | 58 | ### Storage 59 | 60 | The following objectives live under this domain: 61 | 62 | * Understand storage classes, persistent volumes 63 | * Understand volume mode, access modes, and reclaim policies for volumes 64 | * Understand persistent volume claims primitive 65 | * Know how to configure applications with persistent storage 66 | 67 | ### Troubleshooting 68 | 69 | The following objectives live under this domain: 70 | 71 | * Evaluate cluster and node logging 72 | * Understand how to monitor applications 73 | * Manage container stdout & stderr logs 74 | * Troubleshoot application failure 75 | * Troubleshoot cluster component failure 76 | * Troubleshoot networking --------------------------------------------------------------------------------