Introduction to Kubernetes - Cloud Academy course by Logan Rakai
Course Introduction
Part 1 - Introduction
Course Overview
- Kubernetes Overview
- Deploying Containerised Applications to k8s
- The Kubernetes ecosystem
Learning Objectives
- Describe k8s and what it is used for
- Deploy single and multiple container applications on k8s
- Use k8s services to structure N-tier applications
- Manage application deployments with rollouts in k8s
- Ensure container preconditions are met and keep containers healthy
- Learn how to manage configuration, sensitive, and persistent data in k8s
- Discuss popular tools and topics surrounding k8s in the ecosystem
Prerequisites
- Docker
Recommendation: Do the Intro to K8s Playground lab after this lesson
Overview of Kubernetes
Part 2 - Kubernetes Overview
- Open-source orchestration tool designed to automate deploying, scaling, and operating containerised applications.
- Born out of Google’s experience running production workloads at scale
- Allows organisations to increase their velocity by releasing and recovering faster with k8s’ self-healing mechanisms
- K8s is a distributed system
- Machines may be physical, virtual located on-prem or in the cloud
- Schedules containers on machines
- Moves containers as machines are added/removed
- Can use different container runtimes, most commonly Docker
- Modular, extensible design
- Excellent end-user abstractions
- Declarative configuration
- Deploy containers
- Wire up networking
- Scale and expose services
- For Operations
- Automatically recover from machine failures
- Built-in support for machine maintenance
- Join clusters with federation - if one dies, containers will automatically move to other clusters
- Feature highlights
- Automated deployment rollout and rollback
- Seamless horizontal scaling
- Secret management
- Service discovery and load balancing
- Linux and windows container support
- RBAC
- Batch job processing
- CPU and memory quotas
- Persistent volume management
- Stateful application support
- Simple log collection
- There has been a surge in tools to support enterprises adopting containers in production
Part 3 - Deploying Kubernetes
skipped taking notes
Part 4 - Kubernetes Architecture
- K8s clusters are the highest level of abstraction
- Cluster refers to all of the machines collectively and can be thought of as the entire running system
- Nodes are the machines in the clusters. They can be physical or virtual machines
- Nodes are categorised as workers or masters
- Each worker node includes software to run containers managed by the k8s control plane
- Master nodes run the control plane
- The control plane is a set of APIs and software that k8s users interact with
- The APIs and software are referred to as master components
Scheduling
- Control plane schedules containers onto nodes. The term scheduling doesn’t refer to time in this context. Similar to how a kernel schedules processes onto the CPU.
- Scheduling decisions consider required CPU and other factors.
- Scheduling refers to the decision process of placing containers onto nodes.
K8s Pods
- Containers are grouped into pods
- All containers in the pod run on the same node
- Pods are the smallest building block in k8s
- More complex and useful abstractions are built on top of Pods.
K8s Services
- Services define networking rules for exposing groups of Pods
- To other Pods
- To the public internet
K8s Deployments
- Manage deploying configuration changes to running Pods
- Horizontal scaling
Summary
- K8s is a container orchestration tool
- A group of Nodes form a K8s Cluster
- K8s runs containers in groups called Pods
- K8s Services expose Pods to the Cluster and to the public internet
- K8s Deployments control rollout and rollback of Pods
Part 5 - Interacting with Kubernetes
Kubernetes API Server
- Modify cluster state information by sending requests to the K8s API server
- The API server is a master component that acts as the front-end for the cluster
Interacting with K8s
The different methods are as follows
- REST API
- It is possible but not common to work directly with the API server
- You might need to if there is K8s client library for your programming language
- Client Libraries
- Handles authenticating and managing individual REST API requests and responses
- K8s maintains official client libraries for Go, Python, Java, .NET and JS.
- There are also many community-maintained libraries when no official lib exists.
- Command-line tool kubectl - most commonly used
- Issue high-level commands that are translated into REST API calls
- Works with local and remote clusters
- Your k8s success correlates with kubectl skill. You can accomplish all your day-to-day skills with this command
- Manages all different types of k8s resources, and providers debugging and introspection features
- Luckily, kubectl follows easy-to-understand design patterns: when you learn to manage one resource, you learn to manage them all
Basic kubectl
commands
kubectl create
to create resources (Pods, Services, etc.)- Using built-in sub-commands of create or
- By using files. The files are commonly in yaml format and are referred to as manifests
kubectl delete
to delete resourceskubectl get
to get list of resources of a given typekubectl describe
to print detailed info about a resource(s)kubectl logs
to print container logs of a particular pod or of a specific container in a multi-container pod
Web dashboard
- Optional so not all clusters have it but is a great way to get an overview of your cluster(s)
Deploying Containerised Applications to Kubernetes
Part 6 - Pods
- Basic building block in K8s
- One or more containers in a Pod
- Pod containers all share a container network that allows any Pod to talk to any other Pod regardless of which nodes they are running on
- One IP address per Pod
- K8s does all the heavy-lifting to make all of the above happen
What’s in a Pod Declaration
Because Pods include containers, the declaration of a pod includes all of the properties that you would expect for running containers, for example with docker run
. These include the
- Container image
- Container ports
- Container restart policy
- Resource limits
Manifest files
- Declare desired properties
- Manifests can describe all kinds of resources
- The
spec
contains resource-specific properties
Manifests in Action
kubectl create
sends manifest to K8s API Server- API Server does the following for Pod manifests
- Select a node with sufficient resources
- Schedule Pod onto node
- Node pulls Pod’s container image
- Starts Pod’s container
Why Use Manifests?
- Can check into source control
- Easy to share
- Easier to work with than stringing together long sequences of commands
Demo
apiVersion
: v1 is the core apiVersion containing many of the most common resources such as Pods and nodes. K8s supports many apiVersionskind
: indicates what the resource ismetadata
: contains info relevant to the resource and can help identify resources- Minimum metadata is
name
name
must be unique in a namespace
- Minimum metadata is
spec
: specification for the declaredkind
and must match what is expected by the definedapiVersion
- Essentially where all of the meat goes
- K8s cannot update the port on a running pod, so we need to delete and recreate it
- While deleting providing -f file will delete all resources specified in that file
label
: in addition to providing meaningful identification information, labels are used to make selections- Quality of Service Classes
- K8s can schedule pods based on their resource requests. Those pods without resource requests are easier to schedule because the scheduler doesn’t need to find nodes with the requested amount of resources. It will just schedule them onto any node that isn’t under pressure or starved for resources. However, these pods will be the first to be evicted if a node becomes under pressure and needs to free up resources.
- That’s called best effort quality of service. BestEffort pods can also create resource contention with other pods on the same node and usually it is a good idea to set resource requests.
- Specifying the resource requests and limits will use the Guaranteed QoS class
Summary
- Pods are K8s’ basic building block
- Declare Pods and other resources in manifest files
- Manifest files contain
apiVersion
,kind
,metadata
andspec
metadata
includes name (required) and labels (optional but recommended)- Pod
spec
include container names and images
Part 7 - Services
- A Pod is inaccessible apart from other pods in the container network. Even for pods in the container network, it isn’t very convenient to access the web server as it is because pods need to find the IP address of the pod and keep track of any changes to it (remember that k8s will reschedule pods to other nodes, for e.g., if the node fails, in which case the IP will change).
- To overcome all these challenges, there are K8s Services.
- A Service defines networking rules for accessing Pods in the cluster and from the internet.
- Use labels to select a group of Pods.
- Service has a fixed IP address.
-
Distribute requests across Pods in the group to balance the load
- Specify the Pod label so the Service can select the Pods with those labels
- Service is assigned a static IP address and Port. Through this the pod can be reached within the container network and from outside of the cluster.
Manifest
apiVersion
- same as for Pod:v1
kind
- set to ‘Service’metadata
can contain the same labels as that of the Pod since it’s related to the same application. This isn’t required but it is important to stay organised.spec
selector
: required, define the labels to match the pods againstport
: required, refers to the value of the pod’s container porttype
: optional, defines how to actually expose the service- NodePort allocates a port for the service on each node in the cluster. Usually it’s better to allow k8s to choose a port from the available ports to avoid the chance that the port you specify is already taken. That will cause the service to fail to create
Demo
- Cluster - IP - internal IP of the service
- NodePort doesn’t have an external IP
- The allocated port for the service is commonly between 30000 and 32767
Summary
- Services expose Pods via a static IP address
- NodePort Services allows access from outside the cluster
Part 8 - Multi-Container Pods
Agenda
- Multi-container pods
- Namespaces
- Pod Logs
Kubernetes Namespaces
- Namespaces separate resources according to users, environments or applications
- Role-Based Access Control (RBAC) to secure access per Namespace
- Using namespaces is a best practice
Namespace Manifest
- Namespaces don’t require a
spec
. The main thing is themetadata.name
. - It’s a good idea to label it as well
- The
kind
isNamespace
- Create namespace via
kubectl create namespace
or usingkubectl apply -f <manifest file>
- When running
kubectl
commands remember to specify the namespace using the-n
command otherwise thedefault
namespace will be applied - The
-n
command can be specified anytime afterkubectl
word
Multi-Container Manifest
- Don’t mention the namespace in the other resource manifests as it makes those manifests less portable because the provided namespace can’t be overridden at the command line
- Not a good idea to put the “latest” tag in the
containers[x].image
as k8s may pull the latest new version of the image without you realising it which may not be compatible with the rest of your application - To prevent always pulling an image and using an existing image if present you can set the
imagePullPolicy
toIfNotPresent
. Useful to know this but you’re better of using the specific version of the image. - When the specific tags are used, the
imagePullPolicy
is set toIfNotPresent
by default - To talk to other containers within the pod, use the env vars to configure the host (localhost) and the port
- Containers within a pod share the same IP address and so they can reach one another using the localhost and with the container specific port
Logs
kubectl logs
-f
to follow logs real time—tail
to specify number of lines from the last at the point the command is entered
There is an issue with the current design for the example. Since k8s can only scale at a Pod level and not at a container level, if you want to scale up one of the containers you will end up scaling up the containers like the Redis container which means each Redis container will maintain its own counter value which is not desirable. So a better design would be to break apart the application into multiple Pods and connecting them to each other using Services. Having said that, it does make sense to sometimes include multiple containers in a Pod - it comes down to how tightly coupled the containers are and if it makes sense to think of them as a single unit.
Summary
- Containers communicate over localhost within a Pod
kubectl logs
for logs- Logs record what’s written to standard output and standard error
Part 9 - Service Discovery
Why Services?
- Supports multi-Pod design
- Provides static endpoint for each tier
- Handles Pod IP changes
- Load balancing
Service Discovery Mechanisms
- Environment variables
- Service addresses automatically injected in containers
- Env vars follow naming conventions based on service name
- DNS
- DNS records automatically created in cluster’s DNS
- Containers automatically configured to query cluster DNS
Demo
- The yaml file allows us to create multiple resource manifests in a single file by separating them with a line that contains 3 hyphens.
- It’s possible to cram all resource manifests into a single file but grouping the manifests as tiers like data tier, support tier, etc. enables us manage them tier by tier.
- Use labels to group resources together
- For a service to select using a label, the label should be specified in a Pod
- In Service,
port.name
field is required to distinguish between different ports. But optional if there is only 1 port ClusterIP
is the default Service type and sotype
is optional if the intended service type isClusterIP
- It creates a virtual IP inside the cluster for internal access only
- The resources are created in the order they are specified in the manifest file
Environment Variables for Service Discovery
- In the Pod manifest the value for the host and port take the following convention
- IP address:
<all_caps_service_name>_SERVICE_HOST
(Hyphens in service name replaced by “_”) - Port:
<all_caps_service_name>_SERVICE_PORT
- Named port:
<all_caps_service_name>_SERVICE_PORT_<all_caps_port_name>
- For e.g.,
name: REDIS_URL
value: redis://$(DATA_TIER_SERVICE_HOST):$(DATA_TIER_SERVICE_PORT_REDIS)
- IP address:
- When using environment variables in the value field need to enclose them in parentheses and precede it with “$”
- In order to use env vars created by k8s for service discovery, the Service must be created before the Pod.
- K8s doesn’t update env vars of running containers, they only get set at startup.
- The service should also be in the same namespace for the env vars to be available
DNS for Service Discovery
- K8s will add DNS A records for every service
- Naming convention is as follows:
- IP address:
<service_name>.<service_namespace>
. No need to convert hyphens to underscores or all caps when using DNS for service discovery - Port: needs to be extracted from SRV DNS record and that isn’t something we can use in the manifest so we either have to hard-code the port information or use the SERVICE_PORT env var
- However, if the service is in the same namespace, then you can simply use the service name
- For e.g.,
name: API_URL
value: http://app-tier.service-discovery:8080
- The cluster DNS resolves the DNS name to the service IP address.
- IP address:
- It is possible to use the DNS SRV port record to configure the pod on startup using init containers.
Summary
- Services for N-tier applications
- ClusterIP Service for internal-only access
- Environment variables and DNS allow Pods to discover Services
- Environment variables for Services available at Pod creation time and the same Namespace
- DNS dynamically updated and across Namespaces. They overcome the shortcomings of env vars. DNS records are added and deleted from the cluster’s DNS as services are added and deleted. The DNS names allow communication with services in other namespaces.
- SRV DNS records are created for service port information.
Part 10 - Deployments
- Pods should not be created directly, they should be created using higher-level abstractions like Deployments
- Deployments represent multiple replicas of a Pod. The
spec
field contains similar fields as that of a Pod’s manifest - Describe a desired state that K8s needs to achieve
- K8s master components include a Deployment Controller master component which converges actual state to the desired state
Differences between Pod and Deployment manifests
apiVersion
-v1
vsapps/v1
. Higher level abstractions for managing applications are in their own api group and not part of the core API.kind
is set toDeployment
as opposed toPod
spec
- contains deployment specific settings likereplicas
,selector
- Contains
template
wheretemplate.spec
exactly matchesspec
in a Pod selector.matchLabels
should overlap with the labels declared in the pod template belowtemplate.metadata
includes labels on the pods. Note that this metadata doesn’t need aname
because k8s generates a unique name for each pod replica in the deployment.
- Contains
Demo
kubectl scale
with—replicas=5
is similar to editing the replicas value in the Deployment manifest and then runningk apply
- Replicas replicate pods, not containers inside pods.
Summary
- Deployments to manage Pods in each tier
- K8s ensures actual state matches desired state
kubectl scale
to scale number of replicas- Services seamlessly support scaling
- Scaling is best with stateless Pods
Instead of scaling arbitrarily we may want to automatically scale up our resources based on some metrics
Part 11 - Autoscaling
- Scale automatically based on CPU utilisation (or custom metrics)
- Set target CPU along with min and max replicas
- Target CPU is expressed as a percentage of the Pod’s CPU request
- Min. and max. Replicas limits are respected irrespective of the metric percentage
Metrics and CPU requests
- Autoscaling depends on metrics being collected
- Metrics server is one solution for collecting metrics. There are other solutions k8s integrates with to collect metrics
- Several manifest files are used to deploy Metrics Server (https://github.com/kubernetes-incubator/metrics-server)
- We need to use the Metrics Server up and running before we can use Autoscaling.
- Once the metrics server is running, autoscalers can fetch the metrics using the k8s metrics API
- You can confirm that the metrics server is doing its thing by watching the
kubectl top pods
command. It lists the CPU and memory usage of the pods in the namespace. This command can be used to debug resource utilisation issues
- The other thing that the autoscaler depends on is having a CPU request in the deployment’s pod spec.
Autoscaler Manifest
- Autoscaler a.k.a. horizontal pod auto-scaler, is just another resource in k8s
- The
HorizontalPodAutoscaler
kind is a part of theautoscaling/v1
api. - Its
spec
includes theminReplicas
andmaxReplicas
, thetargetCPUUtilizationPercentage
field sets the avg. CPU percentage across the replicas. - If target CPU utilisation is 70%, k8s will reduce the no. of replicas if the CPU util goes below 63% and increase if 77%. Default tolerance is 10%.
- The
spec
also has thescaleTargetRef
field that identifies what it’s scaling. kubectl autoscale
command also achieves the same resultkubectl
accepts short-hand notations for resources, we can usekubectl api-resources
for a full list of shorthand notations
kubectl edit
- combines modifying, saving and applying the manifest into one command- It directly edits the server-side version of the manifest file
- In general, it makes sense to edit the local manifest file so that the changes can be checked-in to source control
- HPA checks about every 15 secs whether it should scale
Summary
- Autoscaling depends on metrics being collected
- Pods must have CPU requests
HorizontalPodAutoscaler
(hpa) is configured with target CPU, and min and max replicas- Once it’s created, k8s does the heavy lifting to dynamically scale the resources
kubectl apply
for applying resources rather than deleting and creatingkubectl edit
to edit and apply
Part 12 - Rolling Updates and Rollbacks
Rollouts
- Rollouts update Deployments
- Any change to a Deployment’s
template
triggers a rollout - Different rollout strategies are available
Rolling Updates
- Default rollout strategy
- Update replicas in groups rather than all-at-once
- This allows service to continue uninterrupted while the update is being rolled out
- However, you need consider that during the rollout the pods will be using both the old and the new configuration and the app should gracefully handle that
- Alternative is the recreate strategy - incurs downtime for the application
- Scaling is not a rollout. Recall that the number of replicas is not a part of the deployment’s
template
kubectl
has commands to check, pause, resume and rollback (undo) rollouts
Demo
- As part of rolling update strategy,
maxSurge
andmaxUnavailable
fields control the rate at which updates are rolled out.maxSurge
specifies how many replicas over the desired total are allowed during a rollout. A higher surge allows new pods to be created without waiting for old ones to be deleted.maxUnavailable
controls how many old pods can be deleted without waiting for new pods to be ready. The defaults are 25%.- You may want to configure them if you want to trade off the impact on availability or resource utilisation with the speed of the rollout. For e.g., you can have all the new pods start immediately but in the worse case you could have all the new pods and all the old pods consuming resources at the same time effectively doubling the resource utilisation for a short period.
- Trigger a rollout by updated a
template
field of the deployment kubectl rollout status
streams progress updates in real timekubectl rollout pause
pauses ongoing rolloutkubectl rollout resume
picks up right where it left off and goes about its businesskubectl rollout undo
to rollback to the previous versionkubectl rollout history
to see the previous revisions and then specify revision to rollback to with the—to-revision
option
Summary
- Rollouts are triggered by Deployment
template
changes - Rolling update is the default rollout strategy
- Rollouts can be paused, resumed and undone
Rollouts depend on container status. K8s assumes that created containers are immediately ready and the rollout should continue. This does not work in all cases. We may need to wait for the web server to accept connections. This is where probes and init containers come into the picture.
Part 13 - Probes
- In the previous lesson and demo, K8s assumed that a pod was ready as soon as the container started. That isn’t always true, for e.g., if the container needs time to warm up K8s should wait before sending any traffic to the new pod.
- It’s also possible that pod is fully operational but after some time it becomes non-responsive, for example if it enters a deadlock state. K8s shouldn’t send any more requests to the pod and would be better off to start a new pod.
- K8s provides probes to remedy both the above situations.
- Probes are sometimes referred to as health checks.
Readiness Probes
- Used to check when Pod is ready to serve traffic / handle requests
- Useful after startup to check external dependencies
- Readiness Probes set the pod’s ready condition. Services only send traffic to ready Pods
Liveness Probes
- Detect when Pod enters a broken state and no longer serve requests
- Kubernetes will restart the Pod for you - key difference between readiness and liveness probes. We have to decide which to use for what based on what course of action we want k8s to take
- Declared in the same way as readiness probes
- Common situation: containers may be live but not ready
Declaring Probes
- Probes can be declared in a Pod’s containers
- All container probes must pass for the Pod to pass
- Probe actions can be a command that runs in the container, an HTTP GET request, or opening a TCP socket
- HTTP request is considered successful if response code is [200,399]
- TCP request is considered successful if a connection can be established
- By default probes check containers every 10 seconds
Demo
- Data Tier (Redis)
- Liveness: Open TCP socket
- Readiness:
redis-cli ping
command - Container may be live but not yet ready
- App Tier (Server)
- L: HTTP GET /probe/liveness
- R: HTTP GET /probe/readiness
- By default 3 sequential probes should fail - so there is some buffer bulit-in. K8s won’t immediately restart if the first probe fails
initialDelaySeconds
for first probe. In general, use a higher delay for liveness probe than readiness probe- Types of probes:
tcpSocket
,httpGet
,exec
andexec.command
- If things go awry, you can use a combination of
describe
and thelogs
command to debug what’s wrong - Unfortunately, failed probe events don’t show in the events output in describe, but you can use the pod restart count as an indicator of failed liveness probes
Summary
- Container readiness probes monitor when Pods are ready to serve traffic and are temporarily out of service
- Container liveness probes monitor when Pods have entered a broken state and should be restarted
- Probe actions include commands, HTTP GET requests, and opening TCP sockets
Probes kick in after containers are started. If you need to start or prepare things before the container starts there is a way to do that as well - init containers.
Part 14 - Init Containers
Motivation for Init Containers
- Sometimes you need to perform tasks to check for pre-reqs before a main container can start - e.g., waiting for a service to be created, etc.
- The code that performs that could be crammed into the main container image but it’s better to separate the initialisation wait logic from the container image
- Initialisation is tightly coupled to the main application and so belongs in the Pod
- Init containers allow you to run initialisation tasks before starting the main containers.
Init containers
- Pods can declare any number of init containers
- Init containers run in order and to completion. Then the main containers in the Pod can start
- Init containers can use their own images different from that of the main container
- Easy way to block or delay starting an application until some preconditions are met. They are similar to readiness probes in that sense but they are only run at Pod startup and can perform other useful work
- All the above features make init containers a vital part of the k8s toolbox
- They are run every time a Pod is created. They are run once for every replica in a deployment. If the Pod restarts due to a failed liveness probe, the init containers would run again as part of the restart. Thus you have to assume that init containers run at least once. Thus you have to ensure init containers are idempotent
Demo
- E.g. use case of init container - add an init container to our app tier that will wait for Redis before starting any application servers
- Init containers have the same fields as regular containers except for
readinessProbe
because they must run to completion before the state of the Pod can be considered ready.
Summary
- Init containers allow you to perform tasks before main application containers have an opportunity to start
- Useful for checking preconditions and preparing dependencies
Part 15 - Volumes
- Containers in a Pod share the same network stack but each has its own file system
- Sometimes useful to share data between containers in a Pod
- Lifetime of container file systems is limited to the container’s lifetime
- Can lead to unexpected consequences if a container restarts
Agenda
- How to handle non-ephemeral data - allowing us to separate data from containers
- Deploy a persistent data tier
- Options available for storing data
Options available for storing data
- 2 high-level storage options: Volumes and Persistent Volumes
- Used by mounting a directory in one or more containers in a Pod
- Pods can use multiple Volumes and Persistent Volumes
- Difference between Volumes and Persistent Volumes is how their lifetime is managed - one depends on lifetime of a particular Pod and the other is independent of the lifetime of Pods.
Volumes
- Volumes are tied to a Pod and their lifecycle
- Share data between containers in a Pod and tolerate container restarts
- Although technically possible, consider using Volumes for non-durable storage that is deleted with the Pod
- Default Volume type is
emptyDir
- creates an initially empty directory on the node running the Pod to back the storage used by the Volume. - Any data written to the directory remains if a container in the Pod is restarted.
- Once the Pod is deleted, the data in the Volume is permanently deleted.
- Note that since the data is stored in a specific node, if a node is rescheduled to a different node, the data will be lost.
- If the data is too valuable to lose when a Pod is deleted or rescheduled you should consider using Persistent Volumes
Persistent Volumes
- Independent of Pod’s lifetime and are separately managed by K8s
- Pods must claim Persistent Volumes to use throughout their lifetime
- Persistent Volumes will continue to exist outside of their pods. They will continue to exist after the Pods that have claimed them have been deleted.
- Can be mounted by multiple Pods on different Nodes if underlying storage supports it
- Can be provisioned statically in advance by the cluster admin or dynamically on-demand for more flexible self-serve use cases Pods must make a request for storage before they can use a persistent volume
Persistent Volume Claims
- Describe a Pod’s request for Persistent Volume storage
- Includes how much storage, type of storage, and access mode
- Access mode can be read-write once, read-only many or read-write many.
- PVC stays pending if no PV can satisfy it and dynamic provisioning is not enabled
- Connects to a Pod through Volume of type PVC
Storage Volume Types
- Wide variety of volume types to choose from
- Use PVs for more durable storage types
- Supported durable storage include GCE Persistent Disks, Azure Disks, Amazon EBS, NFS and iSCSI
Demo
- Deployment, PV and PVC manifests are typically in a single file as they go together
accessMode
can only be one of the 3 modes- The PVC spec outlines what it is looking for in a PV.
- For a PV to be bound to a PVC, it must satisfy all the constraints in the claim.
- Specify
volume
in deployment manifest with thepersistentVolumeClaim.claimName
corresponding to the PVC name - The
volumeMounts[x].mountPath
in the deploymentspec
can be different for different containers even if the volume is the same - To confirm the claims request is satisfied by the PV,
Status: Bound
is present in the describe output.
Summary
- PVs are independent of the lifecycle of the Pods
kubectl exec
runs commands in Pod containers
Part 16 - ConfigMaps and Secrets
Motivation for ConfigMaps and Secrets
- Until now all container configuration has been in the Pod spec
- This makes it less portable than it could be
- If sensitive information such as API keys and passwords is involved it presents a security issue
ConfigMaps and Secrets
- Separate configuration from Pod specs
- Results in easier to manage and more portable manifests
- Both are similar but Secrets are specifically for sensitive data
- Secrets reduce the risk of their data being exposed. However, the cluster administrator also needs to ensure that all the proper encryption and access control safeguards are in place
- There are specialised types of Secrets for storing Docker registry credentials and TLS certs
- We will focus on generic secrets
Using ConfigMaps and Secrets
- Data stored in key-value pairs
- Pods must reference ConfigMaps and Secrets to use their data
- References can be made by mounting Volumes or setting environment variables
Demo
- ConfigMap
kind: ConfigMap
- There is no
spec
. Only adata
field with a singleconfig
key. More than 1 key value pair fordata
is possible - Reference the above config map as a volume in deployment -
spec.volumes[x].configMap
. You can access specific key value pairs defined in the ConfigMap- Then specify the volume under
volumeMounts
in the necessary container
- Then specify the volume under
- Config values can be dynamically changed and they will be picked up by k8s and the mounted volumes will be updated
- Since the deployment’s
template
is not updated, it does not trigger a rollout though. To do this use thekubectl rollout restart
to restart the appropriate deployment
- Secret
kind: Secret
- Along with
data
, there is astringData
field available in Secrets. - K8s automatically decodes the base64 encoded strings when used in a container
- It’s encoding, not encrypting, so it doesn’t provide any security. So treat the encoded strings as sensitive info as well.
- Don’t check-in secret manifests in source control
stringData
allows you to specify secrets without first encoding them since k8s encodes fields underdata
for youstringData
fields are not actually stored in the api server which can be verified when youedit
the Secret- You need to restart rollout for the env vars referencing the secret to take effect
Summary
- ConfigMaps and Secrets separate configuration data form pod specs or what would otherwise be stored in container images
- Both store data as key-value pairs
- Secrets are for sensitive data
- Referenced via Volumes or env vars
The Kubernetes Ecosystem
Part 17 - Kubernetes Ecosystem
- Vibrant ecosystem around the core of K8s
- Helm
- K8s package manager
- Packages are called charts and are installed on your cluster using Helm CLI
- Helm charts make it easy to share complete apps
- Search Helm Hub for public charts
- E.g., use pre-existing templates / charts instead of building from scratch
- Kustomize
- Customise YAML manifests in K8s
- Helps you mange the complexity of your applications. Obvious use case is env-specific deployments
- Works by using a kustomization.yaml file that declares customisation rules
- Original manifesto are untouched and remain usable
- E.g. use cases
- Generating ConfigMaps and Secrets from files
- Configure common fields across multiple resources
- Apply patches to any field in a manifest
- Use overlays to customise base groups of resources
- Prometheus
- Open-source monitoring and alerting system
- A server for pulling in time series metric data and storing it
- Inspired by an internal monitoring tool at Google called borgmon
- De facto standard solution for monitoring K8s
- Prom + K8s
- K8s components supply all their own metrics in Prom format
- Many more metrics than Metrics Server
- Adapter available to autoscale using metrics in Prom rather than CPU utilisation
- Commonly paired with Grafana for visualisation
- Define alert rules and send notifications
- Easily installed via Helm chart
- K8s components supply all their own metrics in Prom format
- Kubeflow
- Makes deployment of machine learning workflows on K8s simple, scalable and portable
- A complete ML stack
- Leverage K8s to deploy anywhere, autoscale, etc.
- Knative
- Platform for building, deploying and managing server less workloads on K8s
- Can be deployed anywhere with K8s, avoiding vendor lock-in
- Supported by Google, IBM and SAP
Course Conclusion
Part 18 - Conclusion
- What K8s is
- K8s Architecture
- K8s in Practice
- Example kubectl commands
- K8s terminology
- N-tier apps and Service discovery
- Deployment rollouts
- Monitoring containers with probes
- Preparing Pods with init containers
- Persistent data storage
- Separating config and sensitive data using ConfigMaps and Secrets
- K8s Ecosystem