In this course, you learn how to deploy and manage Microservices applications with Kubernetes. You also learn about securing and managing a Kubernetes cluster, and how to plan your Kubernetes cluster for deployment to IBM Cloud.
Megan Irvine, Technical Enablement Specialist
Describe Kubernetes architecture and components. Use the Kubernetes CLI to manage Kubernetes objects. Describe how Kubernetes works with containers.
- There are many distributions of Kubernetes available, this course uses the IBM Cloud Kubernetes Service on IBM Cloud
- Receive IBM Digital Badge
- For this course you will earn IBM Cloud: Deploying Microservices with Kubernetes
- Kubernetes is an open-source container orchestrator that was developed by Google to manage applications that run in a container environment
- Rapidly create applications that are failure resilient and scale extremely well
- K8s automates the deployment, scaling, and operation of application containers. and provides tools and APIs to manage production workloads on containers
- Supports multiple cloud and bare-metal environments
- A declarative model that uses YAMLs
- Theee models of closue services -- IaaS, PaaS (where Kubernetes fits), SaaS
- Comparison of deployments with Docker Compose, Docker Swarm and Kubernetes, also Mesos
- Kubernetes is Container Orchestrator with these components:
- Master: API Server, Scheduler, Etcd, Replication Controllers
- Worker Nodes: kube-proxy, kubelet, docker, fluentd, pods
- Docker registry
- The scheduler determines which nodes should run which pod in order to make actual state match the desired one
- A Service is an abstraction that defines a set of Pods as an endpoint, and a policy by which to access them
- Kube-proxy uses cluster IP Address to route requests appropriately to pods belonging to a service
- A Pod can include one or more application containers and some shared resources, such as storage, networking information, and so on
- Deployment YAML file tells Kubernetes how to deploy and manage application instances
- A set of controllers, which run as background threads on the master node, manage routine tasks in the cluster
- Node controller monitors the status of nodes, and responds when one goes down
- Replication controller for maintaining the correct number of Pods for a deployment
- Endpoint controller for connecting services with pods
- These controllers are compiled into a single binary process called kube-controller-manager
- Kubect verb objecttype [subtype] instancename
- Kubeconfig
- Kubernetes resources -- Services, Deployments, ReplicaSets (like Replication Controllers), Pods, Containers
- Kubernetes objects -- namespace, label, selector, annotation, resource quotas, service, secret, deployment, replica set
- Docker is not the only container runtime, see LXC, rkt, runC, systemd and others, but is the most popular
- Container probes -- Liveness and Rediness
- Lifecycle hooks -- PostStart and PreStop
> kubectl exec -ti <pod/container> --namespace <ns>
> kubectl describe <pod/container> --namespace <ns>
> kubectl get [nodes|pods|rc|services]- Additional reading:
Deploy a simple application on a single-node Kubernetes environment. Describe how YAML is used for configuration. Create a Kubernetes cluster on IBM Cloud.
- A configuration script can include one or more of the following sections:
- Deployment: Defines the creation of pods (individual containerized app) and replica sets(multiple instances of pods)
- Service: Provides front-end access to pods
- Ingress: Specifies a type of load balancer that provides routes to access your app publicly
- Pod definition: It describes a single container
- Volume: For applications that require persistent storage
- Multiple containers
- Label definitions: key:value pairs that can be used to organize and select Pods
- Healthchecks (HTTP or TCP) for liveness and readiness
apiVersion: v1
kind: Pod
metadata:
name: simplepod
labels:
app: simple
spec:
containers:
- name: simplepod
image: simple:4.2
ports:
- containerPort: 80
volumeMounts:
- mountPath: /data
name: persistent-storage
livenessProbe:
path: /health
port: 80
volumes:
- name: persistent-storage
emptyDir: {}-
Configuring access to Pods
- NodePort: Expose a public port on every worker node and use the public IP address of any worker node
- LoadBalancer: Create an external TCP/ UDP load balancer for your app
- Ingress: Expose multiple apps in your cluster by creating one external HTTP or HTTPS load balancer
-
Kubernetes Distributions
-
Cluster configuration in IBM Cloud
-
Deploy an application with IBM Kubernetes Service
- IBM Watson Tone Analyzer
- Create a Kubernetes cluster
- Deploy an application
-
Additional reading:
Explain how to configure persistent storage and work with Volumes in Kubernetes. Describe the Kubernetes network model. Describe Kubernetes cluster security considerations and tasks.
- Methods for persisting data
- You can store data by using another cloud service that is hosted either in the private cloud or elsewhere in the enterprise
- After a storage administrator creates a PersistentVolume (PV), a developer can make a PersistentVolumeClaim (PVC) against the PV
- You can persist configuration and settings by using ConfigMaps and Secrets
- A PVC makes a dynamic request for storage by using a defined StorageClass that supports a specific storage provider and set of use cases
- PV is a storage resource in the cluster with a lifecycle is independent of any individual pod that uses it
- Static: A cluster administrator creates several PVs
- Dynamic: When none of the static PVs that the administrator created matches a user’s PVC, the cluster might try to dynamically provision a volume for the PVC
- PVC is a storage request, or claim, that a developer makes. Claims request specific sizes of storage and other aspects, such as access modes
- StorageClass describes an offering of storage and allows for the dynamic provisioning of PVs and PVCs based on those controlled definitions
- ReclaimPolicy for a PV tells the cluster what to do with the volume after it is released of its claim -- retain or delete
- Volume lifecycle
- Access modes define how Volumes can be mounted in the manner that is supported by the storage provider
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: <pvc_name>
annotations:
volume.beta.kubernetes.io/storage-class: "ibmc-file-silver"
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 20Gi- Network model
- All containers (Pods) can communicate with all other containers (Pods), without NAT
- All nodes (and node agents) can communicate with all containers (Pods), and vice versa, without NAT
- Kubernetes assigns every Pod an IP address
- When the cluster is installed, a network_cidr is specified in the config.yaml file
- The default network is 10.0.0.1/16
- Containers within a Pod share the network namespace and IP address, so they can communicate via localhost, and they must also coordinate port usage
- Every Service that is defined in the cluster gets a DNS name
- Service can be found by using environment variables or DNS
- Kube-proxy implements a form of virtual IP for Services, except for Services of the ExternalName type
- Service is an object abstraction that defines a policy for accessing a Pod or set of Pods
- Support TCP (default) and UDP
kind: Service
apiVersion: v1
metadata:
name: my-nginx-service
spec:
selector:
app: skol-nginx
ports:
- protocol: TCP
port: 80
targetPort: 80- Service types determine how the Service is deployed and how it behaves:
- ClusterIP: Exposes the Service internally to the cluster on the cluster IP address. This type is the default.
- NodePort: Exposes the Service on each of the cluster Nodes' IP addresses at the port that NodePort specifies. An associated ClusterIP Service is automatically created. The Service is accessible via :, and internally via the ClusterIP, and is either specified or automatically assigned.
- LoadBalancer: Exposes the Service externally by using a cloud provider’s load balancer. Associated NodePort and ClusterIP Services are created.
- ExternalName: Maps the Service to the externalName field by returning a CNAME record with its value. No proxy of any kind is configured.
- Ingress is not a Service, itself
- The Ingress object sits in front of multiple Services and proxies, and routes traffic into the cluster and to the application
- Can be configured to give services externally-reachable URLs, load balance traffic, terminate SSL, and offer name based virtual hosting
- An Ingress controller fulfills the Ingress, typically with a loadbalancer, or it might also configure an edge router or additional frontends to help handle the traffic
- LoadBalancer provides an externally-accessible IP address that sends traffic to the appropriate port on your cluster nodes
- Use Ingress to provide a unique public route that forwards requests to services in your cluster, based on their individual paths
-
Limit access to the Kubernetes API
- For authorization, Kubernetes provides a Role-Based Access Control (RBAC) component that you can use to assign permissions to roles
- API communication is encrypted, so TLS certificates must be generated and distributed to cluster components
- Kubelets that run on every worker node, by default, allow access to HTTPS endpoints on the node and within containers. To secure these endpoints, enable authentication and authorization for the kubelet.
-
Limit resource usage on a cluster
- Define resource quotas to limit the amount of CPU and memory that can be consumed
-
Define container policies and privileges
- To control what privileges that a pod can run with, you can define a security context for that pod
-
Define network policies
- Namespaces separate resources into administrative groups
- Firewalls and other methods prevent unauthorized cluster access
-
Protect Kubernetes components, such as etcd
- Important yo restrict access to it by using a strong credential from the API server to etcd
- This is covered by mutual authentication with TLS certificates
- Encrypt your backups of etcd by using a reliable backup and encryption solution
- In Kubernetes v1.7, you can use the “encryption at rest” feature to encrypt secret information that is in your etcd
-
Cluster security review
- Make sure that images are not vulnerable to attack and compliant with security policies
- Limit direct access to Kubernetes nodes (such as ssh)
- Create administrative boundaries to isolate and limit access to resources
- Use resource quotas to limit CPU and memory usage
- Use network policies to segregate network traffic and limit access to pods
-
Additional reading:
- The Kubernetes network model
- Ingress Controllers
- Kubelet authentication/authorization
- Kubernetes authorization overview
- Using RBAC autorization
- Manage TLS certificates in a cluster
- Kubelet authentication/authorization
- Resource quotas
- Configure a security context for a pod or container
- Taints and tolerations
- Namespaces
- Encrypting data at rest
- Kubernetes logging architecture
- Project Calico
Plan your cluster deployment. Discuss cluster maintenance tasks. Describe common troubleshooting tools and techniques.
-
Cluster planning
- Where will you run Kubernetes
- Personal computing device, a virtual machine, bare metal servers, in your own data center, or on a cloud service provider
- Kubernetes as a cloud service, e.g. BM Cloud Kuber Service provides a managed Kubernetes environment
- IBM Cloud Private to host Kubernetes in your own data center
- Combine different environments for a hybrid approach
- How will you handle Service registry and discovery
- Kubernetes natively supports service registry, discovery and load balancing
- Leverage the Kubernetes Service type to expose your Microservices, and then it automatically registers with the Kubernetes system by using a virtual IP or DNS approach
- Discovery is through DNS look-up
- For service-based clusters, Kubernetes provides a built-in load balancer to distribute the workload among Pods
- Virtual IP address versus DNS-based service lookup
- This approach requires the Kubernetes DNS plug-in
- Where will you run Kubernetes
-
Node maintenance tasks
- Scaling an application
- Resizing a cluster
- Restarting a Node
- Upgrading a cluster
-
The main Kubernetes components to consider when troubleshooting are:
- etcd, the Kubernetes data store
- kubelet, a process that runs on each cluster node
- kube-apiserver, the Kubernetes API Server
-
Some common problems
-
Example: Debugging an inaccessible cluster
-
Useful tools for monitoring Linux
- top and htop: Linux process ponitoring
- vmstat: virtual memory statistics
- lsof: list open file
- tcpdump: network packet analyzer
- netstat: network statistics
- monitorix: system and network monitoring
- iotop: Monitor Linux Disk I/O
- iostat: Input / Output Statistics
- iptraf: Real Time IP LAN Monitoring
- psacct: Monitor User Activity
- monit: Linux Process & Srvc Monitoring
- nethogs: Monitor Per Process Network
- nmon: Monitor Linux Performance
-
Additional reading: