Kubernetes deep dive

Size: px

Start display at page:

Download "Kubernetes deep dive"

Kristian Douglas
5 years ago
Views:

1 Kubernetes deep dive

2 Hello! אני מיקי חיוט, מתמחה בתחום כ- 20 שנים וב- 4 שנים האחרונות עובד בבית התוכנה "אינפיניטי" המעניק פתרונות טכנולוגיים בתחומי דבאופס, תשתיות, פיתוח, אבטחת מידע ובסיסי נתונים.

3 Kubernetes foundation - Greek for "helmsman" or "pilot" Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications. It groups containers that make up an application into logical units for easy management and discovery. Kubernetes builds upon 15 years of experience of running production workloads at Google, combined with best-of-breed ideas and practices from the community.

4 Kubernetes foundation Why do I need Kubernetes and what can it do? At a minimum, Kubernetes can schedule and run application containers on clusters of physical or virtual machines. How ever, Kubernetes also allow s developers to cut the cord to physical and virtual machines, moving from a host-centric infrastructure to a container-centric infrastructure, which provides the full advantages and benefits inherent to containers. Kubernetes provides the infrastructure to build a truly container-centric development environment.

5 Kubernetes: Kubernetes foundation W hat Kubernetes is not Does not limit the types of applications supported. It does not dictate application frameworks (e.g., Wildfly), restrict the set of supported language runtimes (for example, Java, Python, Ruby), cater to only 12-factor applications, nor distinguish apps from services. Kubernetes aims to support an extremely diverse variety of workloads, including stateless, stateful, and data-processing workloads. If an application can run in a container, it should run great on Kubernetes. Does not provide middleware (e.g., message buses), data-processing frameworks (for example, Spark), databases (e.g., mysql), nor cluster storage systems (e.g., Ceph) as built-in services. Such applications run on Kubernetes. Does not have a click-to-deploy service marketplace. Does not deploy source code and does not build your application. Continuous Integration (CI) workflow is an area where different users and projects have their own requirements and preferences, so it supports layering CI workflows on Kubernetes but doesn t dictate how layering should work. Allows users to choose their logging, monitoring, and alerting systems. (It provides some integrations as proof of concept.) Does not provide nor mandate a comprehensive application configuration language/system (for example, jsonnet). Does not provide nor adopt any comprehensive machine configuration, maintenance, management, or self-healing systems.

6 Containers?? A container (Linux Container) at its core is an allocation, partitioning, and assignment of host (compute) resources such as CPU Shares, Network I/O, Bandwidth, Block I/O, and Memory (RAM) so that kernel level constructs may jail-off, isolate or contain these protected resources so that specific running services (processes) and namespaces may solely utilize them without interfering with the rest of the system. These processes could be lightweight Linux hosts based on a Linux image, multiple web servers and applications, a single subsystem like a database backend, to a single process such as echo Hello with little to no overhead. Commonly known as operating system-level virtualization or OS Virtual Environments containers differ from hypervisor level virtualization. The main difference is that the container model eliminates the hypervisor layer, redundant OS kernels, binaries, and libraries needed to typically run workloads in a VM.

7 Containers vs vms

8 Kubernetes architecture A K8s setup consists of several parts, some of them optional, some mandatory for the whole system to function. This is a high-level diagram of the architecture

9 Kubernet es core concept s

10 Kubernet es core concept s - review A K8s setup consists of several parts, some of them optional, some mandatory for the whole system to function. This is a high-level diagram of the architecture K8s Master K8s Nodes Deployment Service Pod Statefulsets (new in 1.7)

11 Kubernet es core concept s Master Master components provide the cluster s control plane. Master components make global decisions about the cluster (for example, scheduling), and detecting and responding to cluster events (starting up a new pod when a replication controller s replicas field is unsatisfied). Master components can be run on any node in the cluster. However, for simplicity, set up scripts typically start all master components on the same VM, and do not run user containers on this VM Kube-apiserver,etcd, kube-controller-manager, cloud-controller-manager, kube-scheduler, addons, DNS, User interface, container resource monitoring, cluster-level logging

12 Kubernet es core concept s Node A node is a worker machine in Kubernetes, previously known as a minion. A node may be a VM or physical machine, depending on the cluster. Each node has the services necessary to run pods and is managed by the master components. The services on a node include Docker, kubelet and kube-proxy. See The Kubernetes Node section in the architecture design doc for more details. Kubelet, kube-proxy, docker, rkt, supervisord, fluentd,

13 Desired State And the Declarative Model In k8s we use the declarative model instead of procedural model. In the the declarative model we define the desired state of our object. unlike the procedural model where we define steps and execute them. In k8s every configurations is made using the declarative model where we describe the target status of our object So in the procedural model we would run a container like this : Docker run nginx In the declarative model it would be: apiversion: v1 kind: Pod metadata: name: nginx ]spec: containers: name: nginx image: nginx

14 Kubernet es glossary Pod Kubernetes targets the management of elastic applications that consist of multiple microservices communicating with each other. Often those microservices are tightly coupled forming a group of containers that would typically, in a noncontainerized setup run together on one server. This group, the smallest unit that can be scheduled to be deployed through K8s is called a pod. This group of containers would share storage, Linux namespaces, cgroups, IP addresses. These are co-located, hence share resources and are always scheduled together. Pods are not intended to live long. They are created, destroyed and re-created on demand, based on the state of the server and the service itself.

15 Kubernet es glossary Pod - spec yaml apiversion: ext ensions/v1bet a1 kind: Deployment metadata: name: jenkins spec: replicas: 1 template: metadata: labels: app: jenkins spec: cont ainers: - name: jenkins image: jenkins: port s: - containerport: 8080

16 Kubernet es glossary Service As pods have a short lifetime, there is no guarantee about the IP address they are served on. This could make the communication of microservices hard. Imagine a typical Frontend communication with Backend services. Hence K8s has introduced the concept of a service, which is an abstraction on top of a number of pods, typically requiring to run a proxy on top, for other services to communicate with it via a Virtual IP address. This is where you can configure load balancing for your numerous pods and expose them via a service.

17 Kubernet es glossary Service spec - yaml apiversion: v1 kind: Service metadata: name: nginx spec: type: NodePort ports: - port: 80 targetport: 80 selector: app: nginx

18 Kubernet es glossary Deployment A Deployment controller provides declarative updates for Pods and ReplicaSet s. You describe a desired state in a Deployment object, and the Deployment controller changes the actual state to the desired state at a controlled rate. You can define Deployments to create new ReplicaSets, or to remove existing Deployments and adopt all their resources with new Deployments.

19 Kubernet es glossary Deployment - spec yaml apiversion: apps/v1beta1 # for versions before use extensions/v1beta1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 3 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.7.9 ports: - containerport: 80

20 Minikube Minikube is a small k8s cluster installer running a single node as a master that can run on a test or dev machine. On windows machines it installs virtualbox and runs a small vm. To use the cluster we will need the kubectl utility : The project page is here : We will now install it and deploy our first pod

21 Kubernetes components - diving deeper (pods) Ease of use: Users don't need to run their own process managers, worry about signal and exit-code propagation, and so on. Efficiency: Because the infrastructure takes on more responsibility, containers can be more lightweight. Pods provide a great solution for managing groups of closely related containers that depend on each other and need to cooperate on the same host to accomplish their purpose. It's important to remember that pods are considered ephemeral, throwaway entities that can be discarded and replaced at will. Any pod storage is destroyed with its pod. Each pod gets a unique ID (UID), so you can still distinguish between them if necessary.

22 Kubernetes components - diving deeper (pods) A pod is the unit of work in Kubernetes. Each pod contains one or more containers. Pods are always scheduled together (always run on the same machine). All the containers in a pod have the same IP address and port space; they can communicate using localhost or standard inter-process communication. In addition, all the containers in a pod can have access to shared local storage on the node hosting the pod. The shared storage will be mounted on each container. Pods are important feature of Kubernetes. It is possible to run multiple applications inside a single Docker container by having something like supervisor as the main Docker application that runs multiple processes, but this practice is often frowned upon, for the following reasons: Transparency: Making the containers within the pod visible to the infrastructure enables the infrastructure to provide services to those containers, such as process management and resource monitoring. This facilitates a number of conveniences for users. Decoupling software dependencies: The individual containers may be versioned, rebuilt, and redeployed independently. Kubernetes may even support live updates of individual containers someday.

23 Kubernetes components - diving deeper (pods) Pod Yaml example : apiversion: v1 kind: Pod metadata: name: rss-site labels: app: web spec: containers: name: front-end image: nginx ports: containerport: 80 name: rss-reader image: example/rss-phpnginx:v1 ports: containerport: 88 Taking it apart one piece at a time, we start with the API version; here it s just v1. (When we get to deployments, we ll have to specify a different version because Deployments don t exist in v1.) Next, we re specifying that we want to create a Pod; we might specify instead a Deployment, Job, Service, and so on, depending on what we re trying to achieve. Next we specify the metadata. Here we re specifying the name of the Pod, as well as the label we ll use to describe the pod to Kubernetes. Finally, we ll specify the actual objects that make up the pod. The spec property includes any containers, storage volumes, or other pieces that Kubernetes needs to know about, as well as properties such as whether to restart the container if it fails.

24 Deploy pods Pod Yaml example : apiversion: v1 kind: Pod metadata: name: nginx-pod labels: app: web spec: containers: name: front-end image: nginx ports: containerport: 80 Create a new yaml file and type in the content of this folder To apply the yaml and run the pod use : Kubectl apply -f pod.yaml To verify it is running issue a Kubectl get pod

25 Services Services are used to expose some functionality to users or other services. They usually encompass a group of pods, usually identified by you guessed it a label. You can have services that provide access to external resources, or to pods you control directly at the virtual IP level. Native Kubernetes services are exposed through convenient endpoints. Note that services operate at layer 3 (TCP/UDP). Kubernetes 1.2 added the Ingress object, w hich provides access to HTTP objects. More on that later. Services are published or discovered via one of tw o mechanisms: DNS, or environment variables. Services can be load-balanced by Kubernetes. But, developers can choose to manage load balancing themselves in case of services that use external resources or require special treatment. W e can create different types of services : Clusterip Create a clusterip service. externalname Create an ExternalName service. Loadbalancer Create a LoadBalancer service. nodeport Create a NodePort service.

26 Ingress cont roller Kubernetes ingress Kubernetes offers an ingress resource and controller that is designed to expose Kubernetes services to the outside world. You can do it yourself, of course, but many tasks involved in defining ingress are common across most applications for a particular type of ingress such as a web application, CDN, or DDoS protector. You can also write your own ingress objects. The ingress object is often used for smart load balancing and TLS termination. Instead of configuring and deploying your own Nginx server, you can benefit from the built-in ingress.

27 Netw orking and Kubernetes - Hands on!! Kubernetes ingress specs apiversion: extensions/v1beta1 kind: Ingress metadata: name: test annotations: ingress.kubernetes.io/rewrite-target: / spec: rules: - host: foo.bar.com http: paths: - path: /foo backend: servicename: s1 serviceport: 80 - path: /bar backend: servicename: s2 serviceport: 80 SSL in ingress controller apiversion: v1 data: tls.crt: base64 encoded cert tls.key: base64 encoded key kind: Secret metadata: name: testsecret namespace: default type: Opaque apiversion: extensions/v1beta1 kind: Ingress metadata: name: map spec: tls: - secretname: testsecret backend: servicename: s1 serviceport: 80

28 Deploy Services apiversion: v1 kind: Service metadata: name: nginx spec: type: NodePort ports: - port: 80 targetport: 80 selector: app: web This is the declarative way of deploying - We describe the service what ports it exposes and what its backend To deploy we use Kubectl apply -f service.yaml To create a service the iterative way use kuebctl kubectl expose pod PODNAME --port=80 --name=servicename --type=nodeport -- selector=app:web We will discuss the real world scenarios

29 Kubernet es Deployment s Deployments as discussed before are the collection of a pod and its replication attributes In the previous chapter we deployed a pod but what if we wanted to have more than one copy of it? This is taken care by deployments which groups the pod and the replicaset. Next we will deploy a pod using deployment

30 Kubernet es Deployment s apiversion: apps/v1beta1 kind: Deployment metadata: name: nginx-deployment spec: replicas: 3 template: metadata: labels: app: nginx spec: containers: - name: nginx image: nginx:1.7.9 ports: - containerport: 80 To deploy again use kubectl Kubectl apply -f deployment.yaml Use kubectl get deployment to see the deployment And kubectl get pod to see the pods created And kubectl get rcs to see the replicaset

31 Continuous integration with Kubernetes Canary Release is the technique that we use to softly deploy a new version of an application into Production. It consists of letting only a part of the audience get access to the new version of the app, while the rest still access the old version one. This is very useful when we want to be sure about stability in case of any changes which may be breaking, and have big side effects. The point is: canary release has never been easy to be put into practice. Depending on the environment we have, it can take so long to be put in place that we often prefer to leave this away. However, with Docker containers and Kubernetes orchestration it is quite friendly to do that.

32 Continuous integration with Kubernetes Blue-green deployment is a technique that reduces downtime and risk by running two identical production environments called Blue and Green. At any time, only one of the environments is live, with the live environment serving all production traffic. For this example, Blue is currently live and Green is idle. As you prepare a new version of your software, deployment and the final stage of testing takes place in the environment that is not live: in this example, Green. Once you have deployed and fully tested the software in Green, you switch the router so all incoming requests now go to Green instead of Blue. Green is now live, and Blue is idle. This technique can eliminate downtime due to application deployment. In addition, bluegreen deployment reduces risk: if something unexpected happens with your new version on Green, you can immediately roll back to the last version by switching back to Blue.

You compare two web pages by showing the two variants (let's call them A and B)

33 Continuous integration with Kubernetes A/ B testing (sometimes called split testing) is comparing two versions of a web page to see which one performs better. You compare two web pages by showing the two variants (let's call them A and B) to similar visitors at the same time. The one that gives a better conversion rate, wins!

34 Rolling Update Continuous integration with Kubernetes To update a service without an outage, kubectl supports what is called rolling update, which updates one pod at a time, rather than taking down the entire service at the same time. Rolling Update Deployment The Deployment updates Pods in a rolling update fashion when.spec.strategy.type==rollingupdate. You can specify maxunavailable and maxsurge to control the rolling update process.

35 Thanks!

An Introduction to Kubernetes

8.10.2016 An Introduction to Kubernetes Premys Kafka premysl.kafka@hpe.com kafkapre https://github.com/kafkapre { History }???? - Virtual Machines 2008 - Linux containers (LXC) 2013 - Docker 2013 - CoreOS