Appendix 1. Assessments

Chapter 1: Introduction to Kubernetes

1. Minikube, Google Cloud Platform, and Azure Kubernetes Service.
2. Virtual Machines, FreeBSD Jails, LXC (Linux Containers), Open VZ, and Solaris Containers.
3. Memory, filesystem CPU, threads, processes, namespaces, and memory interface files.
4. It allows companies to ship incremental updates to software. It also allows packaging of software from a developer laptop all of the way to production.
5. An account and billing set up. You'll also need to enable the API on GCE.
6. kube-apiserver, etcd, kube-scheduler, kube-controller-manager, and cloud-controller-manager.
7. kops, kubespray, kubeadm, and bootkube.
8. kubeadm.

Chapter 2: Building a Foundation with Core Kubernetes Constructs

1. HTTP, TCP, and application-level health checks
2. ReplicaSet
3. Ecosystem, interface, governance, application, and nucleus

4. Calico and Flannel
5. rkt, kata, frakti, containerd, and runv
6. Cluster control plane, cluster state, and cluster nodes
7. Equality-based selectors

Chapter 3: Working with Networking, Load Balancers, and Ingress

1. Communication is governed between pods, not containers. Pod communication to service is provided by the services object. K8s doesn't use NAT to communicate between containers.
2. Network address translation
3. CNI plugins that use the overlay network, or the kubenet plugin, which uses the bridge and host-local features.
4. Canal, Calico, Flannel, and Kube-router.
5. Pods.
6. Userspace, iptables, and ipvs.
7. Virtual IPs, service proxies, and multi-port.
8. The spec.
9. GCE, nginx, Kong, Traefik, and HAProxy.
10. Use namespaces, RBAC, container permissions, ingress rules, and clear network policing.

Chapter 4: Implementing Reliable, Container-Native Applications

1. The four use cases for Kubernetes deployments are as follows:
   • Roll out a ReplicaSet
   • Update the state of a set of pods
   • Roll back to an earlier version of a deployment
   • Scale up to accommodate cluster load
2. The selector.

3. The record flag, --record.
4. ReplicationControllers.
5. Horizontal pod autoscaling.
6. Scheduled jobs.
7. DaemonSet simply define a pod to run on every single node in the cluster or a defined subset of those nodes. This can be very useful for a number of production–related activities, such as monitoring and logging agents, security agents, and filesystem daemons.

Chapter 5: Exploring Kubernetes Storage Concepts

1. Persistent, temporary disks, cloud volumes, emptyDir, and nfs
2. emptydir
3. EBS volumes in AWS and disk storage on Azure
4. Different application performance or durability requirements.
5. Binding, using, reclaiming, and expanding.
6. Persistent volume claim.

Chapter 6: Application Updates, Gradual Rollouts, and Autoscaling

1. kubectl scale --replicas
2. rolling-update
3. ClientIP
4. Horizontal pod autoscaling
5. CPU and memory usage settings at minimum and maximum values
6. Helm
7. A chart

 

 

Chapter 7: Designing for Continuous Integration and Delivery

1. Node.js
2. Jenkins
3. Helm charts
4. Persistent volume
5. Installing the Jenkins plugin
6. A ReplicationController
7. npm

Chapter 8: Monitoring and Logging

1. cAdvisor and Heapster.
2. Kube-system.
3. Grafana.
4. A collector.
5. Stackdriver.
6. Good reasons to use Prometheus are as follows:
   • Simple to operate: It was built to run as individual servers using local storage for reliability.
   • It's precise: You can use a query language similar to JQL, DDL, DCL, or SQL queries to define alerts and provide a multi-dimensional view of status.
   • Lots of libraries: You can use more than ten languages and numerous client libraries in order to introspect your services and software.
   • Efficient: With data stored in an efficient, custom format both in memory and on disk, you can scale out easily with sharding and federation, creating a strong platform from which to issue powerful queries that can construct powerful data models and ad hoc tables, graphs, and alerts.

 

 

Chapter 10: Designing for High Availability and Scalability

1. Availability, responsivity, and durability.
2. Uptime is the measure of time a given system, application, network, or other logical and physical object has been up and available to be used by the appropriate end user.
3. The five 9s of availability.
4. It means that it fails gracefully.
5. Google Kubernetes Engine (GKE).
6. A set of master nodes that has the Kubernetes control plane and the etcd servers collocated.
7. The Workloads API.

Chapter 11: Kubernetes SIGs, Incubation Projects, and the CNCF

1. Kubernetes and Prometheus.
2. Linkerd, rkt, CNI, TUF, Vitess, CoreDNS, Jaeger, Envoy.
3. Spiffe, Spire, Open Policy Agent, Telepresence, Harbor, TiKV, Cortex, and Buildpacks. See more here: https://www.cncf.io/sandbox-projects/.
4. Committees are there to define meta-standards and address community-wide issues.
5. It's a great way to understand the core concepts and inner workings of Kubernetes. It's a fun way to meet other motivated, smart people. Lastly, Kubernetes, at its essence, is a community project, and relies on the contributions of its members and users.
6. SSH keys and SSL connectivity.

 

 

Chapter 12: Cluster Federation and Multi-Tenancy

1. Using federation, we can run multiple Kubernetes clusters on-premise and in one or more public cloud providers and manage applications utilizing the entire set of our organizational resources.
2. Federation allows you increase the availability and tenancy capabilities of your Kubernetes clusters.
3. Resource synchronization across clusters and multi-cluster service discovery.
4. Kubefed.
5. Federation-controller-manager and the federation-apiserver.
6. HPAs will act in a similar fashion to normal HPAs, with the same functionality and same API-based compatibility—only, with federation, the management of pods will traverse your clusters.
7. Deployments, ReplicaSets, Events, ConfigMaps, DaemonSets, Ingress, Namespaces, Secrets, and Services.

Chapter 13: Cluster Authentication, Authorization, and Container Security

1. Container repository or registry
2. Any three from the following: Node, ABAC, RBAC, Webhook
3. Privileged
4. kubectl get secrets

Chapter 14: Hardening Kubernetes

1. Data encryption, secrets, service discovery, compliance, RBAC, system event tracking, and trend deviation alerts
2. Stackdriver, Sysdig, Datadog, and Sensu
3. Terraform or CloudFormation and Ansible, Chef, or Puppet

4. The principle of least privilege
5. CPU, memory, and limits
6. Maximum and minimum
7. Transport Layer Security (TLS)

Chapter 15: Kubernetes Infrastructure Management

1. kubeadm-dind, Minikube, and Ubuntu on LXD.
2. Google Kubernetes Engine, Amazon Elastic Container Services, Azure Kubernetes Service, and Stackpoint.io.
3. Logging, Authentication, Authorization, and Linux System Parameters.
4. The commands to upgrade each of the major CSPs hosted Kubernetes clusters are as follows:

az aks upgrade --name <CLUSTER_NAME> --resource-group <RESOURCE_GROUP> --kubernetes-version <VERSION> 

gcloud container clusters upgrade <CLUSTER_NAME>

5. Google Compute Platform, with EKS
6. kubectl drain <node>
7. kubectl uncordon <node>