Slide 1

Slide 1 text

1 Migrating Application to Openshift/Kubernetes: Lessons learned from the trenches Vinicius Branda Martinez vinicius@redhat.com @vinimartinez

Slide 2

Slide 2 text

@vinimartinez

Slide 3

Slide 3 text

@vinimartinez

Slide 4

Slide 4 text

@vinimartinez

Slide 5

Slide 5 text

@vinimartinez

Slide 6

Slide 6 text

@vinimartinez vinicius@redhat.com ● +15 anos Trabalhando com TI (EDS, Tata) ● Senior Solution Architect Red Hat (+8) ● Middleware Team Lead ● Distributed Software Architecture (PUC MG) ● Business Administration (FGV) ● Data Processing (FATEC-BS) ● AppDev, Cloud, Hybrid Cloud, DevOps ● Microservices, Kubernetes, CloudNative, ● Systems Integration, Middleware, Security

Slide 7

Slide 7 text

@vinimartinez 1. Limits 2. Sizing 3. Capacity 4. Placement 5. Quotas 6. QoS 7. Application Health/Probes 8. Imagens 9. Monitoramento 10. Automação Agenda

Slide 8

Slide 8 text

@vinimartinez

Slide 9

Slide 9 text

@vinimartinez Openshift Limits

Slide 10

Slide 10 text

@vinimartinez

Slide 11

Slide 11 text

@vinimartinez Operational System Kubelet Eviction Threshold Resources Alocação de Recursos • Node • - OS (system reserved) • - Kubelet (kube reserved) • - Eviction Threshold

Slide 12

Slide 12 text

@vinimartinez Operational System Kubelet Eviction Threshold Resources Alocação de Recursos • Node • - OS (system reserved) • - Kubelet (kube reserved) • - Eviction Threshold

Slide 13

Slide 13 text

@vinimartinez

Slide 14

Slide 14 text

@vinimartinez AI & Big Data Serverless Legacy Apps Microservices

Slide 15

Slide 15 text

@vinimartinez AI & Big Data Serverless Legacy Apps Microservices Pod Placement

Slide 16

Slide 16 text

@vinimartinez AI & Big Data Serverless Legacy Apps Microservices Pod Placement Afinidade/ Anti-Afinidade

Slide 17

Slide 17 text

@vinimartinez AI & Big Data Serverless Legacy Apps Microservices Pod Placement Afinidade/ Anti-Afinidade Node Selector

Slide 18

Slide 18 text

@vinimartinez AI & Big Data Serverless Legacy Apps Microservices Pod Placement Afinidade/ Anti-Afinidade Node Selector Taint & Tolerations

Slide 19

Slide 19 text

@vinimartinez A multi-project quota, defined by a ClusterResourceQuota object, allows quotas to be shared across multiple projects. Resources used in each selected project are aggregated and that aggregate is used to limit resources across all the selected projects. oc create clusterquota for-user \ --project-annotation-selector openshift.io/requester= \ --hard pods=10 \ --hard secrets=20

Slide 20

Slide 20 text

@vinimartinez A resource quota, defined by a ResourceQuota object, provides constraints that limit aggregate resource consumption per project. It can limit the quantity of objects that can be created in a project by type, as well as the total amount of compute resources and storage that may be consumed by resources in that project. apiVersion: v1 kind: ResourceQuota metadata: name: core-object-counts spec: hard: configmaps: "10" persistentvolumeclaims: "4" replicationcontrollers: "20" secrets: "10" requests.cpu: "1" requests.memory: 1Gi requests.ephemeral-storage: 2Gi limits.cpu: "2" limits.memory: 2Gi limits.ephemeral-storage: 4Gi

Slide 21

Slide 21 text

@vinimartinez A LimitRange is a policy to constrain resource allocations (to Pods or Containers) in a namespace. apiVersion: v1 kind: LimitRange metadata: name: ${PROJECT_NAME}-limits creationTimestamp: null spec: limits: - type: Container max: cpu: 4000m memory: 1024Mi min: cpu: 10m memory: 5Mi default: cpu: 4000m memory: 1024Mi defaultRequest: cpu: 100m memory: 512Mi

Slide 22

Slide 22 text

@vinimartinez kubectl create deployment --image=nodejs nodejs-app oc new-app --docker-image=nodejs --name=nodejs-app kubectl create deployment --image=tomcat tomcat-app oc new-app --docker-image=tomcat --name=tomcat-app

Slide 23

Slide 23 text

@vinimartinez

Slide 24

Slide 24 text

@vinimartinez

Slide 25

Slide 25 text

@vinimartinez kubectl create deployment --image=nodejs nodejs-app oc new-app --docker-image=nodejs --name=nodejs-app kubectl create deployment --image=tomcat tomcat-app oc new-app --docker-image=tomcat --name=tomcat-app QoS Best Effort No Request No Limit

Slide 26

Slide 26 text

@vinimartinez kubectl create deployment --image=nodejs nodejs-app oc new-app --docker-image=nodejs --name=nodejs-app kubectl create deployment --image=tomcat tomcat-app oc new-app --docker-image=tomcat --name=tomcat-app QoS Best Effort No Request No Limit Burstable Request < Limit

Slide 27

Slide 27 text

@vinimartinez Guaranteed Request = Limit kubectl create deployment --image=nodejs nodejs-app oc new-app --docker-image=nodejs --name=nodejs-app kubectl create deployment --image=tomcat tomcat-app oc new-app --docker-image=tomcat --name=tomcat-app QoS Best Effort No Request No Limit Burstable Request < Limit

Slide 28

Slide 28 text

@vinimartinez Application Health apiVersion: v1 kind: Pod metadata: labels: test: readiness name: readiness-http spec: containers: - args: image: k8s.gcr.io/readiness readinessProbe: httpGet: # host: my-host # scheme: HTTPS path: /healthz port: 8080 initialDelaySeconds: 15 timeoutSeconds: 1

Slide 29

Slide 29 text

@vinimartinez Application Health apiVersion: v1 kind: Pod metadata: labels: test: liveness name: liveness-http spec: containers: - name: liveness-http image: k8s.gcr.io/liveness args: - /server livenessProbe: httpGet: # host: my-host # scheme: HTTPS path: /healthz port: 8080 httpHeaders: - name: X-Custom-Header value: Awesome

Slide 30

Slide 30 text

@vinimartinez Application Health apiVersion: v1 kind: Pod metadata: labels: test: liveness name: liveness-http spec: containers: - name: liveness-http image: k8s.gcr.io/liveness args: - /server livenessProbe: httpGet: # host: my-host # scheme: HTTPS path: /healthz port: 8080 httpHeaders: - name: X-Custom-Header value: Awesome

Slide 31

Slide 31 text

@vinimartinez Docker Hub Red Hat UBI

Slide 32

Slide 32 text

@vinimartinez Docker Hub Red Hat UBI

Slide 33

Slide 33 text

@vinimartinez Kubernetes Native

Slide 34

Slide 34 text

@vinimartinez Tracing Logging Metrics Structured Logging USE RED SMART Open Tracing

Slide 35

Slide 35 text

@vinimartinez Declarative Management of Kubernetes Objects Using Configuration Files Kubernetes objects can be created, updated, and deleted by storing multiple object configuration files in a directory and using kubectl apply to recursively create and update those objects as needed. This method retains writes made to live objects without merging the changes back into the object configuration files. kubectl diff also gives you a preview of what changes apply will make What is GitOps? GitOps in short is a set of practices to use Git pull requests to manage infrastructure and application configurations. Git repository in GitOps is considered the only source of truth and contains the entire state of the system so that the trail of changes to the system state are visible and auditable. What is a pipeline? A pipeline in software development is an automated process that drives software through a path of building, testing, and deploying code. By automating the process, the objective is to minimize human error and maintain a consistent process for how software is deployed. Tools that are included in the pipeline could include compiling code, unit tests, code analysis, security, and installer creation. For containerized environments, this pipeline would also include packaging the code into a container to be deployed across the hybrid cloud. A pipeline is critical in supporting continuous integration and continuous deployment (CI/CD) processes.

Slide 36

Slide 36 text

@vinimartinez Declarative Management of Kubernetes Objects Using Configuration Files Kubernetes objects can be created, updated, and deleted by storing multiple object configuration files in a directory and using kubectl apply to recursively create and update those objects as needed. This method retains writes made to live objects without merging the changes back into the object configuration files. kubectl diff also gives you a preview of what changes apply will make What is GitOps? GitOps in short is a set of practices to use Git pull requests to manage infrastructure and application configurations. Git repository in GitOps is considered the only source of truth and contains the entire state of the system so that the trail of changes to the system state are visible and auditable. What is a pipeline? A pipeline in software development is an automated process that drives software through a path of building, testing, and deploying code. By automating the process, the objective is to minimize human error and maintain a consistent process for how software is deployed. Tools that are included in the pipeline could include compiling code, unit tests, code analysis, security, and installer creation. For containerized environments, this pipeline would also include packaging the code into a container to be deployed across the hybrid cloud. A pipeline is critical in supporting continuous integration and continuous deployment (CI/CD) processes. AUTOMATIZE TUDO!!

Slide 37

Slide 37 text

3 Obrigado!! Vinicius Branda Martinez vinicius@redhat.com @vinimartinez