Skip to main content
UploadLanguage (EN)Support
BusinessMobileSocial MediaMarketingTechnologyArt & PhotosCareerDesignEducationPresentations & Public SpeakingGovernment & NonprofitHealthcareInternetLawLeadership & ManagementAutomotiveEngineeringSoftwareRecruiting & HRRetailSalesServicesScienceSmall Business & EntrepreneurshipFoodEnvironmentEconomy & FinanceData & AnalyticsInvestor RelationsSportsSpiritualNews & PoliticsTravelSelf ImprovementReal EstateEntertainment & HumorHealth & MedicineDevices & HardwareLifestyle
Araf Karsh Hamid, profile picture
Uploaded byAraf Karsh Hamid
PPSX, PPTX4,183 views

Docker Kubernetes Istio

The document provides a comprehensive overview of containerization technologies, specifically focusing on Docker, Kubernetes, and Istio. It covers essential concepts such as container architecture, image creation, orchestration, networking, and best practices following the 12-factor app methodology. The content is structured around operational tasks for building and managing containers, deployment strategies, and networking configurations within a Kubernetes environment.

Technology◦
Download as PPSX, PPTX
Docker / Kubernetes / Istio Containers Container Orchestration Service Mesh Araf Karsh Hamid : Co-Founder/CTO, MetaMagic Global Inc., NJ, USA
• 12 Factor App Methodology • Docker Concepts • Images and Containers • Anatomy of a Dockerfile • Networking / Volume Docker1 • Kubernetes Concepts • Namespace / Pods / RelicaSet / • Deployment / Service / Ingress • Rollout and Undo / Autoscale Kubernetes2 • Quotas / Limits / QoS • Pod / Node Affinity • Pod Disruption Budget • Persistent Volume / Claims • Secrets / Jobs / Cron • Kubernetes Commands Kubernetes Advanced Concepts4 Agenda • Istio Concepts • Gateway / Virtual Service • Destination Rule / Service Entry • AB Testing using Canary • Beta Testing using Canary • Logging and Monitoring 5 Istio 21-10-2018 2 • Docker / Kubernetes Networking • Pod to Pod Networking • Pod to Service Networking • Ingress and Egress – Internet • Network Policies Kubernetes Networking3 • Docker Best Practices • Kubernetes Best Practices 6 Best Practices
12 Factor App Methodology 21-10-2018 3 4 Backing Services Treat Backing services like DB, Cache as attached resources 5 Build, Release, Run Separate Build and Run Stages 6 Process Execute App as One or more Stateless Process 7 Port Binding Export Services with Specific Port Binding 8 Concurrency Scale out via the process Model 9 Disposability Maximize robustness with fast startup and graceful exit 10 Dev / Prod Parity Keep Development, Staging and Production as similar as possible 11 Logs Treat logs as Event Streams 12 Admin Process Run Admin Tasks as one of Process Source:https://12factor.net/ Factors Description 1 Codebase One Code base tracked in revision control 2 Dependencies Explicitly declare dependencies 3 Configuration Configuration driven Apps 1
High Level Objectives 4 1. Create Docker Images 2. Run Docker Containers for testing. 3. Push the Containers to registry 4. Docker image as part of your Code Pipeline Process. 1. Create Pods (Containers) with Deployments 2. Create Services 3. Create Traffic Rules (Ingress / Gateway / Virtual Service / Destination Rules) 4. Create External Services From Creating a Docker Container to Deploying the Container in Production Kubernetes Cluster. All other activities revolves around these 8 points mentioned below. 1 #19 Slide No’s #19 #19 #22 #40-46 #49 #97-113 #47
Docker Containers Understanding Containers Docker Images / Containers Docker Networking 5
What’s a Container? Virtual Machine Looks like a Walks like a Runs like a 21-10-2018 6 Containers are a Sandbox inside Linux Kernel sharing the kernel with separate Network Stack, Process Stack, IPC Stack etc. 1
Servers / Virtual Machines / Containers Hardware OS BINS / LIB App 1 App 2 App 3 Server Hardware Host OS HYPERVISOR App 1 App 2 App 3 Guest OS BINS / LIB Guest OS BINS / LIB Guest OS BINS / LIB Type 1 Hypervisor Hardware Host OS App 1 App 2 App 3 BINS / LIB BINS / LIB BINS / LIB Container Hardware HYPERVISOR App 1 App 2 App 3 Guest OS BINS / LIB Guest OS BINS / LIB Guest OS BINS / LIB Type 2 Hypervisor21-10-2018 71
Docker containers are Linux Containers CGROUPS NAME SPACES Copy on Write DOCKER CONTAINER • Kernel Feature • Groups Processes • Control Resource Allocation • CPU, CPU Sets • Memory • Disk • Block I/O • Images • Not a File System • Not a VHD • Basically a tar file • Has a Hierarchy • Arbitrary Depth • Fits into Docker Registry • The real magic behind containers • It creates barriers between processes • Different Namespaces • PID Namespace • Net Namespace • IPC Namespace • MNT Namespace • Linux Kernel Namespace introduced between kernel 2.6.15 – 2.6.26 docker runlxc-start 8 https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html/resource_management_guide/ch01 21-10-2018 1
Docker Container – Linux and Windows Control Groups cgroups Namespaces Pid, net, ipc, mnt, uts Layer Capabilities Union File Systems: AUFS, btrfs, vfs Control Groups Job Objects Namespaces Object Namespace, Process Table. Networking Layer Capabilities Registry, UFS like extensions Namespaces: Building blocks of the Containers 21-10-2018 91
Docker Key Concepts • Docker images • A Docker image is a read-only template. • For example, an image could contain an Ubuntu operating system with Apache and your web application installed. • Images are used to create Docker containers. • Docker provides a simple way to build new images or update existing images, or you can download Docker images that other people have already created. • Docker images are the build component of Docker. • Docker containers • Docker containers are similar to a directory. • A Docker container holds everything that is needed for an application to run. • Each container is created from a Docker image. • Docker containers can be run, started, stopped, moved, and deleted. • Each container is an isolated and secure application platform. • Docker containers are the run component of Docker. • Docker Registries • Docker registries hold images. • These are public or private stores from which you upload or download images. • The public Docker registry is called Docker Hub. • It provides a huge collection of existing images for your use. • These can be images you create yourself or you can use images that others have previously created. • Docker registries are the distribution component of Docker. 10 Images Containers 21-10-2018
Docker DaemonDocker Client How Docker works…. $ docker search …. $ docker build …. $ docker container create .. Docker Hub Images Containers $ docker container run .. $ docker container start .. $ docker container stop .. $ docker container ls .. $ docker push …. $ docker swarm .. 21-10-2018 11 21 34 1. Search for the Container 2. Docker Daemon Sends the request to Hub 3. Downloads the image 4. Run the Container from the image 1
Linux Kernel 21-10-2018 12 HOST OS (Ubuntu) Client Docker Daemon Cent OS Alpine Debian HostLinuxKernel Host Kernel Host Kernel Host KernelAll the containers will have the same Host OS Kernel If you require a specific Kernel version then Host Kernel needs to be updated 1
Windows Kernel 21-10-2018 13 HOST OS (Windows 10) Client Docker Daemon Nano Server Server Core Nano Server WindowsKernel Host Kernel Host Kernel Host KernelAll the containers will have the same Host OS Kernel If you require a specific Kernel version then Host Kernel needs to be updated 1
Docker Image structure • Images are read-only. • Multiple layers of image gives the final Container. • Layers can be sharable. • Layers are portable. • Debian Base image • Emacs • Apache • Writable Container 21-10-2018 141
Running a Docker Container $ ID=$(docker container run -d ubuntu –bin/bash -c “while true; do date; sleep 1; done”) Creates a Docker Container of Ubuntu OS and runs the container and execute bash shell with a script. $ docker container logs $ID Shows output from the( bash script) container $ docker container ls List the running Containers $ docker pull ubuntu Docker pulls the image from the Docker Registry 21-10-2018 151
Anatomy of a Dockerfile Command Description Example FROM The FROM instruction sets the Base Image for subsequent instructions. As such, a valid Dockerfile must have FROM as its first instruction. The image can be any valid image – it is especially easy to start by pulling an image from the Public repositories FROM ubuntu FROM alpine MAINTAINER The MAINTAINER instruction allows you to set the Author field of the generated images. MAINTAINER johndoe LABEL The LABEL instruction adds metadata to an image. A LABEL is a key-value pair. To include spaces within a LABEL value, use quotes and blackslashes as you would in command-line parsing. LABEL version="1.0” LABEL vendor=“M2” RUN The RUN instruction will execute any commands in a new layer on top of the current image and commit the results. The resulting committed image will be used for the next step in the Dockerfile. RUN apt-get install -y curl ADD The ADD instruction copies new files, directories or remote file URLs from <src> and adds them to the filesystem of the container at the path <dest>. ADD hom* /mydir/ ADD hom?.txt /mydir/ COPY The COPY instruction copies new files or directories from <src> and adds them to the filesystem of the container at the path <dest>. COPY hom* /mydir/ COPY hom?.txt /mydir/ ENV The ENV instruction sets the environment variable <key> to the value <value>. This value will be in the environment of all "descendent" Dockerfile commands and can be replaced inline in many as well. ENV JAVA_HOME /JDK8 ENV JRE_HOME /JRE8 16 21-10-2018 1
Anatomy of a Dockerfile Command Description Example VOLUME The VOLUME instruction creates a mount point with the specified name and marks it as holding externally mounted volumes from native host or other containers. The value can be a JSON array, VOLUME ["/var/log/"], or a plain string with multiple arguments, such as VOLUME /var/log or VOLUME /var/log VOLUME /data/webapps USER The USER instruction sets the user name or UID to use when running the image and for any RUN, CMD and ENTRYPOINT instructions that follow it in the Dockerfile. USER johndoe WORKDIR The WORKDIR instruction sets the working directory for any RUN, CMD, ENTRYPOINT, COPY and ADD instructions that follow it in the Dockerfile. WORKDIR /home/user CMD There can only be one CMD instruction in a Dockerfile. If you list more than one CMD then only the last CMD will take effect. The main purpose of a CMD is to provide defaults for an executing container. These defaults can include an executable, or they can omit the executable, in which case you must specify an ENTRYPOINT instruction as well. CMD echo "This is a test." | wc - EXPOSE The EXPOSE instructions informs Docker that the container will listen on the specified network ports at runtime. Docker uses this information to interconnect containers using links and to determine which ports to expose to the host when using the –P flag with docker client. EXPOSE 8080 ENTRYPOINT An ENTRYPOINT allows you to configure a container that will run as an executable. Command line arguments to docker run <image> will be appended after all elements in an exec form ENTRYPOINT, and will override all elements specified using CMD. This allows arguments to be passed to the entry point, i.e., docker run <image> -d will pass the -d argument to the entry point. You can override the ENTRYPOINT instruction using the docker run --entrypoint flag. ENTRYPOINT ["top", "-b"] 21-10-2018 171
Build Docker Containers as easy as 1-2-3 21-10-2018 18 Create Dockerfile 1 Build Image 2 Run Container 3 1
Build a Docker Java image 1. Create your Dockerfile • FROM • RUN • ADD • WORKDIR • USER • ENTRYPOINT 2. Build the Docker image 3. Run the Container $ docker build -t org/java:8 . 191 $ docker container run –it org/java:8
Docker Container Management $ ID=$(docker container run –it ubuntu /bin/bash $ docker container stop $ID Start the Container and Store ID in ID field Stop the container using Container ID $ docker container stop $(docker container ls –aq) Stops all the containers $ docker container rm $ID Remove the Container $ docker container rm $(docker container ls –aq) Remove ALL the Container (in Exit status) $ docker container prune Remove ALL stopped Containers) $ docker container run –restart=Policy –d –it ubuntu /sh Policies = NO / ON-FAILURE / ALWAYS $ docker container run –restart=on-failure:3 –d –it ubuntu /sh Will re-start container ONLY 3 times if a failure happens $ docker container start $ID Start the container 21-10-2018 201
Docker Container Management $ ID=$(docker container run –d -i ubuntu) $ docker container exec -it $ID /bin/bash Start the Container and Store ID in ID field Inject a Process into Running Container $ ID=$(docker container run –d –i ubuntu) $ docker container exec inspect $ID Start the Container and Store ID in ID field Read Containers MetaData $ docker container run –it ubuntu /bin/bash # apt-get update # apt-get install—y apache2 # exit $ docker container ls –a $ docker container commit –author=“name” – message=“Ubuntu / Apache2” containerId apache2 Docker Commit • Start the Ubuntu Container • Install Apache • Exit Container • Get the Container ID (Ubuntu) • Commit the Container with new name $ docker container run –cap-drop=chown –it ubuntu /sh To prevent Chown inside the Container 21-10-2018 211 Source: https://github.com/meta-magic/kubernetes_workshop
Docker Image Commands $ docker login …. Log into the Docker Hub to Push images $ docker push image-name Push the image to Docker Hub $ docker image history image-name Get the History of the Docker Image $ docker image inspect image-name Get the Docker Image details $ docker image save –output=file.tar image-name Save the Docker image as a tar ball. $ docker container export –output=file.tar c79aa23dd2 Export Container to file. 21-10-2018 221 Source: https://github.com/meta-magic/kubernetes_workshop
Build Docker Apache image 1. Create your Dockerfile • FROM alpine • RUN • COPY • EXPOSE • ENTRYPOINT 2. Build the Docker image 3. Run the Container $ docker build -t org/apache2 . $ docker container run –d –p 80:80 org/apache2 $ curl localhost 21-10-2018 231
Build Docker Tomcat image 1. Create your Dockerfile • FROM alpine • RUN • COPY • EXPOSE • ENTRYPOINT 2. Build the Docker image 3. Run the Container $ docker build -t org/tomcat . $ docker container run –d –p 8080:8080 org/tomcat $ curl localhost:8080 21-10-2018 241
Docker Images in the Github Workshop Ubuntu JRE 8 JRE 11 Tomcat 8 Tomcat 9 My App 1 Tomcat 9 My App 3 Spring Boot My App 4 From Ubuntu Build My Ubuntu From My Ubuntu Build My JRE8 From My Ubuntu Build My JRE11 From My JRE 11 Build My Boot From My Boot Build My App 4 From My JRE8 Build My TC8 From My TC8 Build My App 1 21-10-2018 25 My App 2 1 Source: https://github.com/meta-magic/kubernetes_workshop
Docker Networking • Docker Networking – Bridge / Host / None • Docker Container sharing IP Address • Docker Communication – Node to Node • Docker Volumes 21-10-2018 261
Docker Networking – Bridge / Host / None $ docker network ls $ docker container run --rm --network=host alpine brctl show $ docker network create tenSubnet –subnet 10.1.0.0/16 21-10-2018 271
Docker Networking – Bridge / Host / None $ docker container run --rm –net=host alpine ip address$ docker container run --rm alpine ip address $ docker container run –rm –net=none alpine ip address No Network Stack https://docs.docker.com/network/#network-drivers 21-10-2018 281
Docker Containers Sharing IP Address $ docker container run –itd –name ipctr alpine ip address $ docker container run –rm –net container:ipctr alpine ip address IP (Container) Service 1 (Container) Service 3 (Container) Service 2 (Container) 21-10-2018 291
Docker Networking: Node to Node eth0 Container 1 172.17.3.2 Web Server 8080 eth0 Container 2 172.17.3.3 Microservice 9002 eth0 Container 3 172.17.3.4 Microservice 9003 eth0 Container 4 172.17.3.5 Microservice 9004 Docker0 172.17.3.1/16 IP tables rules eth0 10.130.1.101/24 Node 1 eth0 Container 1 172.17.3.2 Web Server 8080 eth0 Container 2 172.17.3.3 Microservice 9002 eth0 Container 3 172.17.3.4 Microservice 9003 eth0 Container 4 172.17.3.5 Microservice 9004 Docker0 172.17.3.1/16 IP tables rules eth0 10.130.1.102/24 Node 2 Same IP Addresses for the Containers across different Nodes. This requires NAT. 21-10-2018 301
Docker Volumes $ docker volume create hostvolume Data Volumes are special directory in the Docker Host. $ docker volume ls $ docker container run –it –rm –v hostvolume:/data alpine # echo “This is a test from the Container” > /data/data.txt 21-10-2018 311 Source:https://github.com/meta-magic/kubernetes_workshop
Docker Volumes $ docker container run - - rm –v $HOME/data:/data alpine Mount Specific File Path 21-10-2018 321 Source:https://github.com/meta-magic/kubernetes_workshop
Kubernetes 21-10-2018 33
Deployment – Updates and rollbacks, Canary Release D ReplicaSet – Self Healing, Scalability, Desired State R Worker Node 1 Master Node (Control Plane) Kubernetes Architecture POD POD itself is a Linux Container, Docker container will run inside the POD. PODs with single or multiple containers (Sidecar Pattern) will share Cgroup, Volumes, Namespaces of the POD. (Cgroup / Namespaces) Scheduler Controller Manager Using yaml or json declare the desired state of the app. State is stored in the Cluster store. Self healing is done by Kubernetes using watch loops if the desired state is changed. POD POD POD BE 1.210.1.2.34 BE 1.210.1.2.35 BE 1.210.1.2.36 BE 15.1.2.100 DNS: a.b.com 1.2 Service Pod IP Address is dynamic, communication should be based on Service which will have routable IP and DNS Name. Labels (BE, 1.2) play a critical role in ReplicaSet, Deployment, & Services etc. Cluster Store etcd Key Value Store Pod Pod Pod Label Selector selects pods based on the Labels. Label Selector Label Selector Label Selector Node Controller End Point Controller Deployment Controller Pod Controller …. Labels Internet Firewall K8s Cluster Cloud Controller For the cloud providers to manage nodes, services, routes, volumes etc. Kubelet Node Manager Container Runtime Interface Port 10255 gRPC ProtoBuf Kube-Proxy Network Proxy TCP / UDP Forwarding IPTABLES / IPVS Allows multiple implementation of containers from v1.7 RESTful yaml / json $ kubectl …. Port 443API Server Pod IP ...34 ...35 ...36EP • Declarative Model • Desired State Key Aspects Namespace1Namespace2 • Pods • ReplicaSet • Deployment • Service • Endpoints • StatefulSet • Namespace • Resource Quota • Limit Range • Persistent Volume Kind Secrets Kind • apiVersion: • kind: • metadata: • spec: Declarative Model • Pod • ReplicaSet • Service • Deployment • Virtual Service • Gateway, SE, DR • Policy, MeshPolicy • RbaConfig • Prometheus, Rule, • ListChekcer … @ @ Annotations Names Cluster IP Node Port Load Balancer External Name @ Ingress 21-10-2018 342
Ubuntu Installation Kubernetes Setup – Minikube $ sudo snap install kubectl --classic 21-10-2018 35 Install Kubectl using Snap Package Manager $ kubectl version Shows the Current version of Kubectl • Minikube provides a developer environment with master and a single node installation within the Minikube with all necessary add-ons installed like DNS, Ingress controller etc. • In a real world production environment you will have master installed (with a failover) and ‘n’ number of nodes in the cluster. • If you go with a Cloud Provider like Amazon EKS then the node will be created automatically based on the load. • Minikube is available for Linux / Mac OS and Windows. $ curl -Lo minikube https://storage.googleapis.com/minikube/releases/v0.30.0/minikube-linux-amd64 $ chmod +x minikube && sudo mv minikube /usr/local/bin/ https://kubernetes.io/docs/tasks/tools/install-kubectl/ 2 Source: https://github.com/meta-magic/kubernetes_workshop
Windows Installation Kubernetes Setup – Minikube C:> choco install kubernetes-cli 21-10-2018 36 Install Kubectl using Choco Package Manager C:> kubectl version Shows the Current version of Kubectl Mac OS Installation $ brew install kubernetes-cli Install Kubectl using brew Package Manager $ kubectl version Shows the Current version of Kubectl C:> cd c:usersyouraccount C:> mkdir .kube Create .kube directory $ curl -Lo minikube https://storage.googleapis.com/minikube/releases/v0.30.0/minikube-darwin-amd64 $ chmod +x minikube && sudo mv minikube /usr/local/bin/ C:> minikube-installer.exe Install Minikube using Minikube Installer https://kubernetes.io/docs/tasks/tools/install-kubectl/ 2 Source: https://github.com/meta-magic/kubernetes_workshop
Kubernetes Setup – Master / Nodes $ kubeadm init node1$ kubeadm join --token enter-token-from-kubeadm-cmd Node-IP:Port Adds a Node $ kubectl get nodes $ kubectl cluster-info List all Nodes $ kubectl run hello-world --replicas=7 --labels="run=load-balancer-example" --image=metamagic/hello:1.0 --port=8080 Creates a Deployment Object and a ReplicaSet object with 7 replicas of Hello-World Pod running on port 8080 $ kubectl expose deployment hello-world --type=LoadBalancer --name=hello-world-service List all the Hello-World Deployments$ kubectl get deployments hello-world Describe the Hello-World Deployments$ kubectl describe deployments hello-world List all the ReplicaSet$ kubectl get replicasets Describe the ReplicaSet$ kubectl describe replicasets List the Service Hello-World-Service with Custer IP and External IP $ kubectl get services hello-world-service Describe the Service Hello-World-Service$ kubectl describe services hello-world-service Creates a Service Object that exposes the deployment (Hello-World) with an external IP Address. List all the Pods with internal IP Address $ kubectl get pods –o wide $ kubectl delete services hello-world-service Delete the Service Hello-World-Service $ kubectl delete deployment hello-world Delete the Hello-Word Deployment Create a set of Pods for Hello World App with an External IP Address (Imperative Model) Shows the cluster details $ kubectl get namespace Shows all the namespaces $ kubectl config current-context Shows Current Context 21-10-2018 372 Source: https://github.com/meta-magic/kubernetes_workshop
21-10-2018 38 Focus on the Declarative Model 2
3 Fundamental Concepts 1. Desired State 2. Current State 3. Declarative Model 21-10-2018 392
Kubernetes Commands – Namespace (Declarative Model) $ kubectl config set-context $(kubectl config current-context) --namespace=your-ns The above command will let you switch the namespace to your namespace (your-ns). $ kubectl get namespace $ kubectl describe ns ns-name $ kubectl create –f app-ns.yml List all the Namespaces Describe the Namespace Create the Namespace $ kubectl apply –f app-ns.yml Apply the changes to the Namespace $ kubectl get pods –namespace= ns-name List the Pods from your namespace • Namespaces are used to group your teams and software’s in logical business group. • A definition of Service will add a entry in DNS with respect to Namespace. • Not all objects are there in Namespace. Ex. Nodes, Persistent Volumes etc. 21-10-2018 402
• Pod is a shared environment for one of more Containers. • Pod in a Kubernetes cluster has a unique IP address, even Pods on the same Node. • Pod is a pause Container Kubernetes Pods $ kubectl create –f app1-pod.yml $ kubectl get pods Atomic Unit ContainerPodVirtual Server SmallBig 21-10-2018 412 Source: https://github.com/meta-magic/kubernetes_workshop
Kubernetes Commands – Pods (Declarative Model) $ kubectl exec pod-name ps aux $ kubectl exec –it pod-name sh $ kubectl exec –it –container container-name pod-name sh By default kubectl executes the commands in the first container in the pod. If you are running multiple containers (sidecar pattern) then you need to pass –container flag and give the name of the container in the Pod to execute your command. You can see the ordering of the containers and its name using describe command. $ kubectl get pods $ kubectl describe pods pod-name $ kubectl get pods -o json pod-name $ kubectl create –f app-pod.yml List all the pods Describe the Pod details List the Pod details in JSON format Create the Pod Execute commands in the first Container in the Pod Log into the Container Shell $ kubectl get pods -o wide List all the Pods with Pod IP Addresses $ kubectl apply –f app-pod.yml Apply the changes to the Pod $ kubectl replace –f app-pod.yml Replace the existing config of the Pod $ kubectl describe pods –l app=name Describe the Pod based on the label value 21-10-2018 422 $ kubectl logs pod-name container-name Source: https://github.com/meta-magic/kubernetes_workshop
• Pods wrap around containers with benefits like shared location, secrets, networking etc. • ReplicaSet wraps around Pods and brings in Replication requirements of the Pod • ReplicaSet Defines 2 Things • Pod Template • Desired No. of Replicas Kubernetes ReplicaSet What we want is the Desired State. Game On! 21-10-2018 432 Source: https://github.com/meta-magic/kubernetes_workshop
Kubernetes Commands – ReplicaSet (Declarative Model) $ kubectl delete rs/app-rs cascade=false $ kubectl get rs $ kubectl describe rs rs-name $ kubectl get rs/rs-name $ kubectl create –f app-rs.yml List all the ReplicaSets Describe the ReplicaSet details Get the ReplicaSet status Create the ReplicaSet which will automatically create all the Pods Deletes the ReplicaSet. If the cascade=true then deletes all the Pods, Cascade=false will keep all the pods running and ONLY the ReplicaSet will be deleted. $ kubectl apply –f app-rs.yml Applies new changes to the ReplicaSet. For example Scaling the replicas from x to x + new value. 21-10-2018 442
Kubernetes Commands – Deployment (Declarative Model) • Deployments manages ReplicaSets and • ReplicaSets manages Pods • Deployment is all about Rolling updates and • Rollbacks • Canary Deployments 21-10-2018 452 Source: https://github.com/meta-magic/kubernetes_workshop
Kubernetes Commands – Deployment (Declarative Model) List all the Deployments Describe the Deployment details Show the Rollout status of the Deployment Creates Deployment Deployments contains Pods and its Replica information. Based on the Pod info Deployment will start downloading the containers (Docker) and will install the containers based on replication factor. Updates the existing deployment. Show Rollout History of the Deployment $ kubectl get deploy app-deploy $ kubectl describe deploy app-deploy $ kubectl rollout status deployment app-deploy $ kubectl rollout history deployment app-deploy $ kubectl create –f app-deploy.yml $ kubectl apply –f app-deploy.yml --record $ kubectl rollout undo deployment app-deploy - -to-revision=1 $ kubectl rollout undo deployment app-deploy - -to-revision=2 Rolls back or Forward to a specific version number of your app. $ kubectl scale deployment app-deploy - -replicas=6 Scale up the pods to 6 from the initial 2 Pods. 21-10-2018 462 Source: https://github.com/meta-magic/kubernetes_workshop
Kubernetes Services Why do we need Services? • Accessing Pods from Inside the Cluster • Accessing Pods from Outside • Autoscale brings Pods with new IP Addresses or removes existing Pods. • Pod IP Addresses are dynamic. Service will have a stable IP Address. Service uses Labels to associate with a set of Pods Service Types 1. Cluster IP (Default) 2. Node Port 3. Load Balancer 4. External Name21-10-2018 472 Source: https://github.com/meta-magic/kubernetes_workshop
Kubernetes Commands – Service / Endpoints (Declarative Model) $ kubectl delete svc app-service $ kubectl create –f app-service.yml List all the Services Describe the Service details List the status of the Endpoints Create a Service for the Pods. Service will focus on creating a routable IP Address and DNS for the Pods Selected based on the labels defined in the service. Endpoints will be automatically created based on the labels in the Selector. Deletes the Service. $ kubectl get svc $ kubectl describe svc app-service $ kubectl get ep app-service $ kubectl describe ep app-service Describe the Endpoint Details  Cluster IP (default) - Exposes the Service on an internal IP in the cluster. This type makes the Service only reachable from within the cluster.  Node Port - Exposes the Service on the same port of each selected Node in the cluster using NAT. Makes a Service accessible from outside the cluster using <NodeIP>:<NodePort>. Superset of ClusterIP.  Load Balancer - Creates an external load balancer in the current cloud (if supported) and assigns a fixed, external IP to the Service. Superset of NodePort.  External Name - Exposes the Service using an arbitrary name (specified by external Name in the spec) by returning a CNAME record with the name. No proxy is used. This type requires v1.7 or higher of kube-dns. 21-10-2018 482 Source: https://github.com/meta-magic/kubernetes_workshop
Kubernetes Ingress (Declarative Model) An Ingress is a collection of rules that allow inbound connections to reach the cluster services. Ingress is still a beta feature in Kubernetes Ingress Controllers are Pluggable. Ingress Controller in AWS is linked to AWS Load Balancer. Source: https://kubernetes.io/docs/concepts/services-networking/ingress/#ingress-controllers 21-10-2018 492 Source: https://github.com/meta-magic/kubernetes_workshop
Kubernetes Ingress (Declarative Model) An Ingress is a collection of rules that allow inbound connections to reach the cluster services. Ingress is still a beta feature in Kubernetes Ingress Controllers are Pluggable. Ingress Controller in AWS is linked to AWS Load Balancer. Source: https://kubernetes.io/docs/concepts/services-networking/ingress/#ingress-controllers 21-10-2018 502
Kubernetes Auto Scaling Pods (Declarative Model) • You can declare the Auto scaling requirements for every Deployment (Microservices). • Kubernetes will add Pods based on the CPU Utilization automatically. • Kubernetes Cloud infrastructure will automatically add Nodes if it ran out of available Nodes. CPU utilization kept at 10% to demonstrate the auto scaling feature. Ideally it should be around 80% - 90% 21-10-2018 512 Source: https://github.com/meta-magic/kubernetes_workshop
Kubernetes Horizontal Pod Auto Scaler $ kubectl autoscale deployment appname --cpu-percent=50 --min=1 --max=10 $ kubectl run -it podshell --image=metamagicglobal/podshell Hit enter for command prompt $ while true; do wget -q -O- http://yourapp.default.svc.cluster.local; done Deploy your app with auto scaling parameters Generate load to see auto scaling in action $ kubectl get hpa $ kubectl attach podshell-name -c podshell -it To attach to the running container 21-10-2018 522 Source: https://github.com/meta-magic/kubernetes_workshop
Kubernetes Networking • Comparison between Docker and Kubernetes Networking • Kubernetes DNS • Pod to Pod Networking within the same Node • Pod to Pod Networking across the Node • Pod to Service Networking • Ingress - Internet to Service Networking • Egress – Pod to Internet Networking 21-10-2018 533
Kubernetes Networking Mandatory requirements for Network implementation 1. All Pods can communicate with All other Pods without using Network Address Translation (NAT). 2. All Nodes can communicate with all the Pods without NAT. 3. The IP that is assigned to a Pod is the same IP the Pod sees itself as well as all other Pods in the cluster.21-10-2018 543 Source: https://github.com/meta-magic/kubernetes_workshop
Kubernetes Networking 3 Networks Networks 1. Physical Network 2. Pod Network 3. Service Network 21-10-2018 553 Source: https://github.com/meta-magic/kubernetes_workshop CIDR Range (RFC 1918) 1. 10.0.0.0/8 2. 172.0.0.0/11 3. 192.168.0.0/16 Keep the Address ranges separate.
Kubernetes Networking 3 Networks 563 Source: https://github.com/meta-magic/kubernetes_workshop eth0 10.130.1.102/24 Node 1 veth0 eth0 Pod 1 Container 1 10.17.4.1 eth0 Pod 2 Container 1 10.17.4.2 veth1 eth0 10.130.1.103/24 Node 2 veth1 eth0 Pod 1 Container 1 10.17.5.1 eth0 10.130.1.104/24 Node 3 veth1 eth0 Pod 1 Container 1 10.17.6.1 Service EP EP EP VIP 172.10.1.2/16 1. Physical Network 2. Pod Network 3. Service Network End Points handles dynamic IP Addresses of the Pods selected by a Service based on Pod Labels
Docker Networking Vs. Kubernetes Networking eth0 Container 1 172.17.3.2 Web Server 8080 eth0 Container 2 172.17.3.3 Microservice 9002 eth0 Container 3 172.17.3.4 Microservice 9003 eth0 Container 4 172.17.3.5 Microservice 9004 Docker0 172.17.3.1/16 IP tables rules eth0 10.130.1.101/24 Node 1 eth0 Container 1 172.17.3.2 Web Server 8080 eth0 Container 2 172.17.3.3 Microservice 9002 eth0 Container 3 172.17.3.4 Microservice 9003 eth0 Container 4 172.17.3.5 Microservice 9004 Docker0 172.17.3.1/16 IP tables rules eth0 10.130.1.102/24 Node 2 eth0 Container 1 10.17.3.2 Web Server 8080 eth0 Container 2 10.17.3.3 Microservice 9002 eth0 Container 3 10.17.3.4 Microservice 9003 eth0 Container 4 10.17.3.5 Microservice 9004 L2 Bridge 10.17.3.1/16 IP tables rules eth0 10.130.1.101/24 Node 1 eth0 Container 1 10.17.4.2 Web Server 8080 eth0 Container 2 10.17.4.3 Microservice 9002 eth0 Container 3 10.17.4.4 Microservice 9003 eth0 Container 4 10.17.4.5 Microservice 9004 L2 bridge 10.17.4.1/16 IP tables rules eth0 10.130.1.102/24 Node 2 Same IP Range NAT Required Uniq IP Range Based on netFilter & IP Tables or IPVS No NAT Docker Networking Kubernetes Networking21-10-2018 573
Kubernetes DNS Kubernetes DNS to avoid IP Addresses in the configuration or Application Codebase. It Configures Kubelet running on each Node so the containers uses DNS Service IP to resolve the IP Address. A DNS Pod consists of three separate containers 1. Kube DNS: Watches the Kubernetes Master for changes in Service and Endpoints 2. DNS Masq: Adds DNS caching to Improve the performance 3. Sidecar: Provides a single health check endpoint to perform health checks for Kube DNS and DNS Masq. • DNS Pod itself is a Kubernetes Service with a Cluster IP. • DNS State is stored in etcd. • Kube DNS uses a library the converts etcd name – value pairs into DNS Records. • Core DNS is similar to Kube DNS but with a plugin Architecture in v1.11 Core DNS is the default DNS Server.21-10-2018 583 Source: https://github.com/meta-magic/kubernetes_workshop
Kubernetes: Pod to Pod Networking inside a Node By Default Linux has a Single Namespace and all the process in the namespace share the Network Stack. If you create a new namespace then all the process running in that namespace will have its own Network Stack, Routes, Firewall Rules etc. $ ip netns add namespace1 A mount point for namespace1 is created under /var/run/netns Create Namespace $ ip netns List Namespace eth0 10.130.1.101/24 Node 1 Root NW Namespace L2 Bridge 10.17.3.1/16 veth0 veth1 ForwardingTables BridgeimplementsARPtodiscoverlink- layerMACAddress eth0 Container 1 10.17.3.2 Pod 1 Container 2 10.17.3.2 eth0 Pod 2 Container 1 10.17.3.3 1. Pod 1 sends packet to eth0 – eth0 is connected to veth0 2. Bridge resolves the Destination with ARP protocol and 3. Bridge sends the packet to veth1 4. veth1 forwards the packet directly to Pod 2 thru eth0 1 2 4 3 This entire communication happens in localhost. So Data transfer speed will NOT be affected by Ethernet card speed. Kube Proxy 21-10-2018 593
eth0 10.130.1.102/24 Node 2 Root NW Namespace L2 Bridge 10.17.4.1/16 veth0 Kubernetes: Pod to Pod Networking Across Node eth0 10.130.1.101/24 Node 1 Root NW Namespace L2 Bridge 10.17.3.1/16 veth0 veth1 ForwardingTables eth0 Container 1 10.17.3.2 Pod 1 Container 2 10.17.3.2 eth0 Pod 2 Container 1 10.17.3.3 1. Pod 1 sends packet to eth0 – eth0 is connected to veth0 2. Bridge will try to resolve the Destination with ARP protocol and ARP will fail because there is no device connected to that IP. 3. On Failure Bridge will send the packet to eth0 of the Node 1. 4. At this point packet leaves eth0 and enters the Network and network routes the packet to Node 2. 5. Packet enters the Root namespace and routed to the L2 Bridge. 6. veth0 forwards the packet to eth0 of Pod 3 1 2 4 3 eth0 Pod 3 Container 1 10.17.4.1 5 6 Kube ProxyKube Proxy Src: Pod1 – Dst: Pod3 21-10-2018 603
eth0 10.130.1.102/24 Node 2 Root NW Namespace L2 Bridge 10.17.4.1/16 veth0 Kubernetes: Pod to Service to Pod – Load Balancer eth0 10.130.1.101/24 Node 1 Root NW Namespace L2 Bridge 10.17.3.1/16 veth0 veth1 ForwardingTables eth0 Container 1 10.17.3.2 Pod 1 Container 2 10.17.3.2 eth0 Pod 2 Container 1 10.17.3.3 1. Pod 1 sends packet to eth0 – eth0 is connected to veth0 2. Bridge will try to resolve the Destination with ARP protocol and ARP will fail because there is no device connected to that IP. 3. On Failure Bridge will give the packet to Kube Proxy 4. it goes thru ip tables rules installed by Kube Proxy and rewrites the Dst-IP with Pod3-IP. IP tables has done the Cluster load Balancing directly on the node and packet is given to eth0. 5. Now packet leaves Node 1 eth0 and enters the Network and network routes the packet to Node 2. 6. Packet enters the Root namespace and routed to the L2 Bridge. 7. veth0 forwards the packet to eth0 of Pod 3 1 2 4 3 eth0 Pod 3 Container 1 10.17.4.1 5 6 Kube ProxyKube Proxy 7 Src: Pod1 – Dst: Service1 Src: Pod1 – Dst: Pod3 21-10-2018 613
eth0 10.130.1.102/24 Node 2 Root NW Namespace L2 Bridge 10.17.4.1/16 veth0 Kubernetes Pod to Service to Pod – Return Journey eth0 10.130.1.101/24 Node 1 Root NW Namespace L2 Bridge 10.17.3.1/16 veth0 veth1 ForwardingTables eth0 Container 1 10.17.3.2 Pod 1 Container 2 10.17.3.2 eth0 Pod 2 Container 1 10.17.3.3 1. Pod 3 receives data from Pod 1 and sends the reply back with Source as Pod3 and Destination as Pod1 2. Bridge will try to resolve the Destination with ARP protocol and ARP will fail because there is no device connected to that IP. 3. On Failure Bridge will give the packet Node 2 eth0 4. Now packet leaves Node 2 eth0 and enters the Network and network routes the packet to Node 1. (Dst = Pod1) 5. it goes thru ip tables rules installed by Kube Proxy and rewrites the Src-IP with Service-IP. Kube Proxy gives the packet to L2 Bridge. 6. L2 bridge makes the ARP call and hand over the packet to veth0 7. veth0 forwards the packet to eth0 of Pod1 1 2 4 3 eth0 Pod 3 Container 1 10.17.4.1 5 6 Kube ProxyKube Proxy 7 Src: Pod3 – Dst: Pod1Src: Service1– Dst: Pod1 21-10-2018 623
Kubernetes: Pod to Internet eth0 10.130.1.101/24 Node 1 Root NW Namespace L2 Bridge 10.17.3.1/16 veth0 veth1 ForwardingTables eth0 Container 1 10.17.3.2 Pod 1 Container 2 10.17.3.2 eth0 Pod 2 Container 1 10.17.3.3 1. Pod 1 sends packet to eth0 – eth0 is connected to veth0 2. Bridge will try to resolve the Destination with ARP protocol and ARP will fail because there is no device connected to that IP. 3. On Failure Bridge will give the packet to IP Tables 4. The Gateway will reject the Pod IP as it will recognize only the VM IP. So source IP is replaced with VM-IP 5. Packet enters the network and routed to Internet Gateway. 6. Packet reaches the GW and it replaces the VM-IP (internal) with an External IP. 7. Packet Reaches External Site (Google) 1 2 4 3 5 6 Kube Proxy 7 Src: Pod1 – Dst: Google Src: VM-IP – Dst: Google Gateway Google Src: Ex-IP – Dst: Google On the way back the packet follows the same path and any Src IP mangling is un done and each layer understands VM-IP and Pod IP within Pod Namespace. 63 VM 3
eth0 10.130.1.102/24 Node X Root NW Namespace L2 Bridge 10.17.4.1/16 veth0 Kubernetes: Internet to Pod 1. Client Connects to App published Domain. 2. Once the Load Balancer receives the packet it picks a VM. 3. Once inside the VM IP Tables knows how to redirect the packet to the Pod using internal load Balancing rules installed into the cluster using Kube Proxy. 4. Traffic enters Kubernetes cluster and reaches the Node X 5. Node X gives the packet to the L2 Bridge 6. L2 bridge makes the ARP call and hand over the packet to veth0 7. veth0 forwards the packet to eth0 of Pod 8 1 2 4 3 5 6 7 Src: Client IP – Dst: App Dst Src: Client IP – Dst: Pod IP Ingress Load Balancer Client / User Src: Client IP – Dst: VM-IP eth0 Pod 8 Container 1 10.17.4.1 Kube Proxy 21-10-2018 64 VM VMVM 3
Networking Glossary Layer 2 Networking Layer 2 is the Data Link Layer (OSI Mode) providing Node to Node Data Transfer. Layer 4 Networking Transport layer controls the reliability of a given link through flow control. Layer 7 Networking Application layer networking (HTTP, FTP etc) This is the closet layer to the end user. Source Network Address Translation SNAT refers to a NAT procedure that modifies the source address of an IP Packet. Destination Network Address Translation DNAT refers to a NAT procedure that modifies the Destination address of an IP Packet. Netfilter – Packet Filtering in Linux Software that does packet filtering, NAT and other Packet mangling IP Tables It allows Admin to configure the netfilter for managing IP traffic. ConnTrack Conntrack is built on top of netfilter to handle connection tracking.. IPVS – IP Virtual Server Implements a transport layer load balancing as part of the Linux Kernel. It’s similar to IP Tables and based on netfilter hook function and uses hash table for the lookup. 21-10-2018 653 Source: https://github.com/meta-magic/kubernetes_workshop
Kubernetes Network Policies 21-10-2018 663 Source: https://github.com/meta-magic/kubernetes_workshop
21-10-2018 67 OSI Layers 3
Kubernetes Pods Advanced • Quality of Service: Resource Quota and Limits • Environment Variables and Config Maps • Pod in Depth / Secrets / Presets • Pod Disruption Range • Pod / Node Affinity • Persistent Volume / Persistent Volume Claims 21-10-2018 684
Kubernetes Pod Quality of Service Source: https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/ QoS: Guaranteed Memory limit = Memory Request CPU Limit = CPU Request QoS: Burstable != Guaranteed and Has either Memory OR CPU Request QoS: Best Effort No Memory OR CPU Request / limits 21-10-2018 694 Source: https://github.com/meta-magic/kubernetes_workshop
• A resource quota, defined by a Resource Quota object, provides constraints that limit aggregate resource consumption per namespace. • It can limit the quantity of objects that can be created in a namespace by type, as well as the total amount of compute resources that may be consumed by resources in that project. Kubernetes Resource Quotas Source: https://kubernetes.io/docs/concepts/policy/resource-quotas/ 21-10-2018 704 Source: https://github.com/meta-magic/kubernetes_workshop
• Limits specifies the Max resource a Pod can have. • If there is NO limit is defined, Pod will be able to consume more resources than requests. However, the eviction chances of Pod is very high if other Pods with Requests and Resource Limits are defined. Kubernetes Limit Range 21-10-2018 714 Source: https://github.com/meta-magic/kubernetes_workshop
Kubernetes Pod Environment Variables 21-10-2018 724 Source: https://github.com/meta-magic/kubernetes_workshop
Kubernetes Adding Config to Pod Config Maps allow you to decouple configuration artifacts from image content to keep containerized applications portable. Source: https://kubernetes.io/docs/tasks/configure-pod-container/configure-pod-configmap/ 21-10-2018 734 Source: https://github.com/meta-magic/kubernetes_workshop
A probe is an indicator to a container's health. It judges the health through periodically performing a diagnostic action against a container via kubelet: • Liveness probe: Indicates whether a container is alive or not. If a container fails on this probe, kubelet kills it and may restart it based on the restartPolicy of a pod. • Readiness probe: Indicates whether a container is ready for incoming traffic. If a pod behind a service is not ready, its endpoint won't be created until the pod is ready. Kubernetes Pod in Depth 3 kinds of action handlers can be configured to perform against a container: exec: Executes a defined command inside the container. Considered to be successful if the exit code is 0. tcpSocket: Tests a given port via TCP, successful if the port is opened. httpGet: Performs an HTTP GET to the IP address of target container. Headers in the request to be sent is customizable. This check is considered to be healthy if the status code satisfies: 400 > CODE >= 200. Additionally, there are five parameters to define a probe's behavior: initialDelaySeconds: How long kubelet should be waiting for before the first probing. successThreshold: A container is considered to be healthy when getting consecutive times of probing successes passed this threshold. failureThreshold: Same as preceding but defines the negative side. timeoutSeconds: The time limitation of a single probe action. periodSeconds: Intervals between probe actions.21-10-2018 744 Source: https://github.com/meta-magic/kubernetes_workshop
• Liveness probe: Indicates whether a container is alive or not. If a container fails on this probe, kubelet kills it and may restart it based on the restartPolicy of a pod. Kubernetes Pod Liveness Probe Source: https://kubernetes.io/docs/tasks/configure-pod- container/configure-liveness-readiness-probes/ 21-10-2018 754 Source: https://github.com/meta-magic/kubernetes_workshop
Kubernetes Pod Secrets Objects of type secret are intended to hold sensitive information, such as passwords, OAuth tokens, and ssh keys. Putting this information in a secret is safer and more flexible than putting it verbatim in a pod definition or in a docker Source: https://kubernetes.io/docs/concepts/configuration/secret/ 21-10-2018 764 Source: https://github.com/meta-magic/kubernetes_workshop
Kubernetes Pod Presets A Pod Preset is an API resource for injecting additional runtime requirements into a Pod at creation time. You use label selectors to specify the Pods to which a given Pod Preset applies. Using a Pod Preset allows pod template authors to not have to explicitly provide all information for every pod. This way, authors of pod templates consuming a specific service do not need to know all the details about that service. Source: https://kubernetes.io/docs/concepts/workloads/pods/podpreset/ 21-10-2018 774 Source: https://github.com/meta-magic/kubernetes_workshop
• A PDB limits the number pods of a replicated application that are down simultaneously from voluntary disruptions. • Cluster managers and hosting providers should use tools which respect Pod Disruption Budgets by calling the Eviction API instead of directly deleting pods. Kubernetes Pod Disruption Range Source: https://kubernetes.io/docs/tasks/run-application/configure-pdb/ $ kubectl drain NODE [options] 21-10-2018 784 Source: https://github.com/meta-magic/kubernetes_workshop
• You can constrain a pod to only be able to run on particular nodes or to prefer to run on particular nodes. There are several ways to do this, and they all uselabel selectors to make the selection. • Assign the label to Node • Assign Node Selector to a Pod Kubernetes Pod/Node Affinity / Anti-Affinity Source: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/ $ kubectl label nodes k8s.node1 disktype=ssd 21-10-2018 794 Source: https://github.com/meta-magic/kubernetes_workshop
Kubernetes Pod Configuration Source: https://kubernetes.io/docs/user-journeys/users/application-developer/advanced/ Pod configuration You use labels and annotations to attach metadata to your resources. To inject data into your resources, you’d likely create ConfigMaps (for non-confidential data) or Secrets (for confidential data). Taints and Tolerations - These provide a way for nodes to “attract” or “repel” your Pods. They are often used when an application needs to be deployed onto specific hardware, such as GPUs for scientific computing. Read more. Pod Presets - Normally, to mount runtime requirements (such as environmental variables, ConfigMaps, and Secrets) into a resource, you specify them in the resource’s configuration file. PodPresets allow you to dynamically inject these requirements instead, when the resource is created. For instance, this allows team A to mount any number of new Secrets into the resources created by teams B and C, without requiring action from B and C. 21-10-2018 804 Source: https://github.com/meta-magic/kubernetes_workshop
Kubernetes Volumes for Stateful Pods 21-10-2018 81 Provision Network Storage Static / Dynamic 1 Request Storage 2 Use Storage 3 4 Persistent Volume / Storage Class Persistent Volume Claim Claims are mounted as Volumes inside the Pod
Kubernetes Volume Persistent Volume • A Persistent Volume is the physical storage available. • Storage Class is used to configure custom Storage option (nfs, cloud storage) in the cluster. They are the foundation of Dynamic Provisioning. • Persistent Volume Claim is used to mount the required storage into the Pod. • ReadOnlyMany: Can be mounted as read-only by many nodes • ReadWriteOnce: Can be mounted as read-write by a single node • ReadWriteMany: Can be mounted as read-write by many nodes Access Mode Source: https://kubernetes.io/docs/concepts/storage/persistent-volumes/#claims-as-volumes Persistent Volume Persistent Volume Claim Storage Class 824 Volume Mode • There are two modes • File System and or • raw Storage Block. • Default is File System. Retain: The volume will need to be reclaimed manually Delete: The associated storage asset, such as AWS EBS, GCE PD, Azure disk, or OpenStack Cinder volume, is deleted Recycle: Delete content only (rm -rf /volume/*) Reclaim Policy
Kubernetes Volume Types 834 Host Based o EmptyDir o HostPath o Local Block Storage o Amazon EBS o OpenStack Cinder o GCE Persistent Disk o Azure Disk o vSphere Volume Others o iScsi o Flocker o Git Repo o Quobyte Distributed File System o NFS o Ceph o Gluster o FlexVolume o PortworxVolume o Amazon EFS o Azure File System Life cycle of a Persistent Volume o Provisioning o Binding o Using o Releasing o Reclaiming Source: https://github.com/meta-magic/kubernetes_workshop
Kubernetes Persistent Volume - hostPath 844 • HostPath option is to make the Volume available from the Host Machine. • A Volume is created and its linked with a storage provider. In the following example the storage provider is Minikube for the host path. • Any PVC (Persistent Volume Claim) will be bound to the Persistent Volume which matches the storage class. • If it doesn't match a dynamic persistent volume will be created. Storage class is mainly meant for dynamic provisioning of the persistent volumes. Persistent Volume is not bound to any specific namespace. Change the above path in your system 1 Source: https://github.com/meta-magic/kubernetes_workshop
Persistent Volume - hostPath 854 Pod Access storage by issuing a Persistent Volume Claim. In the following example Pod claims for 2Gi Disk space from the network on the host machine. • Persistent Volume Claim and Pods with Deployment properties are bound to a specific namespace. • Developer is focused on the availability of storage space using PVC and is not bothered about storage solutions or provisioning. • Ops Team will focus on Provisioning of Persistent Volume and Storage class. 2 3 Source: https://github.com/meta-magic/kubernetes_workshop
Persistent Volume - hostPath 864 Running the Yaml’s from the Github 2 3 1 1. Create Static Persistent Volumes and Dynamic Volumes (using Storage Class) 2. Persistent Volume Claim is created and bound static and dynamic volumes. 3. Pods refer PVC to mount volumes inside the Pod. Source: https://github.com/meta-magic/kubernetes_workshop
Kubernetes Persistent Volume – AWS EBS 874 • Use a Network File System or Block Storage for Pods to access and data from multiple sources. AWS EBS is such a storage system. • A Volume is created and its linked with a storage provider. In the following example the storage provider is AWS for the EBS. • Any PVC (Persistent Volume Claim) will be bound to the Persistent Volume which matches the storage class. 1 Volume ID is auto generated$ aws ec2 create-volume - -size 100 Storage class is mainly meant for dynamic provisioning of the persistent volumes. Persistent Volume is not bound to any specific namespace. Source: https://github.com/meta-magic/kubernetes_workshop
Persistent Volume – AWS EBS 884 Pod Access storage by issuing a Persistent Volume Claim. In the following example Pod claims for 2Gi Disk space from the network on AWS EBS. • Manual Provisioning of the AWS EBS supports ReadWriteMany, However all the pods are getting scheduled into a Single Node. • For Dynamic Provisioning use ReadWriteOnce. • Google Compute Engine also doesn't support ReadWriteMany for dynamic provisioning. 2 3 https://cloud.google.com/kubernetes-engine/docs/concepts/persistent-volumes Source:https://github.com/meta-magic/kubernetes_workshop
Kubernetes Advanced features • Jobs • Daemon Set • Container Level features • Kubernetes Commands – Quick Help • Kubernetes Commands – Field Selectors 21-10-2018 894
A job creates one or more pods and ensures that a specified number of them successfully terminate. As pods successfully complete, the job tracks the successful completions. When a specified number of successful completions is reached, the job itself is complete. Deleting a Job will cleanup the pods it created. A simple case is to create one Job object in order to reliably run one Pod to completion. The Job object will start a new Pod if the first pod fails or is deleted (for example due to a node hardware failure or a node reboot). A Job can also be used to run multiple pods in parallel. Kubernetes Jobs Source: https://kubernetes.io/docs/concepts/workloads/controllers/jobs-run-to-completion/21-10-2018 904 Command is wrapped for display purpose. Source: https://github.com/meta-magic/kubernetes_workshop
Kubernetes DaemonSet A DaemonSet ensures that all (or some) Nodes run a copy of a Pod. As nodes are added to the cluster, Pods are added to them. As nodes are removed from the cluster, those Pods are garbage collected. Deleting a DaemonSet will clean up the Pods it created. Some typical uses of a DaemonSet are: • running a cluster storage daemon, such as glusterd, ceph, on each node. • running a logs collection daemon on every node, such as fluentd or logstash. • running a node monitoring daemon on every node, such as Prometheus Node Exporter, collectd, Dynatrace OneAgent, Datadog agent, New Relic agent, Ganglia gmond or Instana agent. 21-10-2018 914 Source: https://github.com/meta-magic/kubernetes_workshop
Container-level features Sidecar container: Although your Pod should still have a single main container, you can add a secondary container that acts as a helper (see a logging example). Two containers within a single Pod can communicate via a shared volume. Init containers: Init containers run before any of a Pod’s app containers (such as main and sidecar containers) Kubernetes Container Level Features Source: https://kubernetes.io/docs/user-journeys/users/application-developer/advanced/ 21-10-2018 924
Kubernetes Commands – Quick Help $ kubectl create –f app-rs.yml $ kubectl get rs/app-rs $ kubectl get rs $ kubectl delete rs/app-rs cascade=false $ kubectl describe rs app-rs $ kubectl apply –f app-rs.yml Cascade=true will delete all the pods $ kubectl get pods $ kubectl describe pods pod-name $ kubectl get pods -o json pod-name $ kubectl create –f app-pod.yml $ kubectl get pods –show-labels $ kubectl exec pod-name ps aux $ kubectl exec –it pod-name sh Pods ReplicaSet (Declarative Model) $ kubectl get pods –all-namespaces $ kubectl apply –f app-pod.yml $ kubectl replace –f app-pod.yml $ kubectl replace –f app-rs.yml 21-10-2018 934 Source: https://github.com/meta-magic/kubernetes_workshop
Kubernetes Commands – Quick Help $ kubectl create –f app-service.yml $ kubectl get svc $ kubectl describe svc app-service $ kubectl get ep app-service $ kubectl describe ep app-service $ kubectl delete svc app-service $ kubectl create –f app-deploy.yml $ kubectl get deploy app-deploy $ kubectl describe deploy app-deploy $ kubectl rollout status deployment app-deploy$ kubectl apply –f app-deploy.yml $ kubectl rollout history deployment app-deploy $ kubectl rollout undo deployment app-deploy - -to-revision=1 Service Deployment (Declarative Model) $ kubectl apply –f app-service.yml $ kubectl replace –f app-service.yml $ kubectl replace –f app-deploy.yml 21-10-2018 944 Source: https://github.com/meta-magic/kubernetes_workshop
Kubernetes Commands – Field Selectors $ kubectl get pods --field-selector status.phase=Running Get the list of pods where status.phase = Running Source: https://kubernetes.io/docs/concepts/overview/working-with-objects/field-selectors/ Field selectors let you select Kubernetes resources based on the value of one or more resource fields. Here are some example field selector queries: • metadata.name=my-service • metadata.namespace!=default • status.phase=Pending Supported Operators You can use the =, ==, and != operators with field selectors (= and == mean the same thing). This kubectl command, for example, selects all Kubernetes Services that aren’t in the default namespace: $ kubectl get services --field-selector metadata.namespace!=default 21-10-2018 954
Kubernetes Commands – Field Selectors $ kubectl get pods --field-selector=status.phase!=Running,spec.restartPolicy=Always Source: https://kubernetes.io/docs/concepts/overview/working-with-objects/field-selectors/ Chained Selectors As with label and other selectors, field selectors can be chained together as a comma-separated list. This kubectl command selects all Pods for which the status.phase does not equal Running and the spec.restartPolicy field equals Always: Multiple Resource Type You use field selectors across multiple resource types. This kubectl command selects all Statefulsets and Services that are not in the default namespace: $ kubectl get statefulsets,services --field-selector metadata.namespace!=default 21-10-2018 964
Service Mesh: Istio Gateway Virtual Service Destination Rule 97
• Enforces access control and usage policies across service mesh and • Collects telemetry data from Envoy and other services. • Also includes a flexible plugin model. Mixer Provides • Service Discovery • Traffic Management • Routing • Resiliency (Timeouts, Circuit Breakers, etc.) Pilot Provides • Strong Service to Service and end user Authentication with built-in Identity and credential management. • Can enforce policies based on Service identity rather than network controls. Citadel Provides • Configuration Injection • Processing and • Distribution Component of Istio Galley Control Plane Envoy is deployed as a Sidecar in the same K8S Pod. • Dynamic Service Discovery • Load Balancing • TLS Termination • HTTP/2 and gRPC Proxies • Circuit Breakers • Health Checks • Staged Rollouts with % based traffic split • Fault Injection • Rich Metrics Envoy Data Plane Istio Components 21-10-2018 985
Service Mesh – Sidecar Design Pattern 21-10-2018 99 CB – Circuit Breaker LB – Load Balancer SD – Service Discovery Microservice Process1Process2 Service Mesh Control Plane Service Discovery Routing Rules Control Plane will have all the rules for Routing and Service Discovery. Local Service Mesh will download the rules from the Control pane will have a local copy. Service Discovery Calls Service Mesh Calls Customer Microservice Application Localhost calls http://localhost/order/processOrder Router Network Stack LBCB SD ServiceMesh Sidecar UI Layer Web Services Business Logic Order Microservice Application Localhost calls http://localhost/payment/processPayment Router Network Stack LBCB SD ServiceMesh Sidecar UI Layer Web Services Business Logic Data Plane 5 Source: https://github.com/meta-magic/kubernetes_workshop
Service Mesh – Traffic Control 21-10-2018 100 API Gateway End User Business Logic Service Mesh Sidecar Customer Service Mesh Control Plane Admin Traffic Rules Traffic Control rules can be applied for • different Microservices versions • Re Routing the request to debugging system to analyze the problem in real time. • Smooth migration path Business Logic Service Mesh Sidecar Business Logic Service Mesh Sidecar Business Logic Service Mesh Sidecar Business Logic Service Mesh Sidecar Business Logic Service Mesh Sidecar Order v1.0 Business Logic Service Mesh Sidecar Business Logic Service Mesh Sidecar Order v2.0 Service Cluster 5 Source: https://github.com/meta-magic/kubernetes_workshop