Share
Embed
How to Code, Deploy, and Operate Cloud-Native Apps Using Kubernetes
This presentation talks about Cloud-Native definition and puprpose, 12-Factor app as a methodology to build, deploy, and operate Cloud-Native applications. Finally, we talk about Kubernetes and how to build Cloud-Native applications using Kubernetes.
Aditya Satrya
November 02, 2019
Transcript
47 slides
-
Outline • Cloud-Native & 12-Factor App • Kubernetes • 12-Factor
App using Kubernetes -
Cloud-Native Application • Operability: Expose control of application/system lifecycle. •
Observability: Provide meaningful signals for observing state, health, and performance. • Elasticity: Grow and shrink to fit in available resources and to meet fluctuating demand. • Resilience: Fast automatic recovery from failures. • Agility: Fast deployment, iteration, and reconfiguration -
Cloud-Native Trail Map 1. Containerization 2. CI/CD 3. Orchestration --below
this are optional-- 4. Observability 5. Service Discovery 6. Networking & Policy 7. Distributed database & storage 8. Streaming & messaging 9. Container registry 10. Software distribution -
12-Factor App • Methodology to build app optimized for the
cloud (cloud-native) • Drafted by developers at Heroku (2011) • http://12factor.net -
Code I. One Codebase One codebase tracked in revision control,
many deploys II. Dependencies Explicitly declare and isolate dependencies III. Config Store config in the environment VI. Processes Execute the app as one or more stateless processes IV. Backing services Treat backing services as attached resources V. Build, release, run Strictly separate build and run stages X. Dev/prod parity Keep development, staging, and production as similar as possible VII. Port binding Export services via port binding VIII. Concurrency Scale out via the process model IX. Disposability Maximize robustness with fast startup and graceful shutdown XI. Logs Treat logs as event streams XII. Admin processes Run admin tasks as one-off processes Deploy Operate -
What is Kubernetes? • Open-source system for automating: ◦ deployment
◦ scaling ◦ management of containerized applications -
Worker 1 Worker 2 Worker 3 Worker 4 Worker 5
Master 1 Master 2 Master 3 Workers -
Worker 1 Worker 2 Worker 3 Worker 4 Worker 5
Master 1 Master 2 Master 3 Workers -
Worker 1 Worker 2 Worker 3 Worker 4 Worker 5
Master 1 Master 2 Master 3 Workers Run 5 instances of frontend:latest -
Worker 1 Worker 2 Worker 3 Worker 4 Worker 5
Master 1 Master 2 Master 3 Workers Run 5 instances of frontend:latest -
Worker 1 Worker 2 Worker 3 Worker 4 Worker 5
Master 1 Master 2 Master 3 Workers Run 5 instances of frontend:latest frontend: 4/5 X -
Worker 1 Worker 2 Worker 3 Worker 4 Worker 5
Master 1 Master 2 Master 3 Workers Run 5 instances of frontend:latest frontend: 4/5 -
Worker 1 Worker 2 Worker 3 Worker 4 Worker 5
Master 1 Master 2 Master 3 Workers Run 5 instances of frontend:latest frontend: 5/5 -
Worker 1 Worker 2 Worker 3 Worker 4 Worker 5
Master 1 Master 2 Master 3 Workers Run 5 instances of frontend:latest Run 3 instances of backend:latest -
Worker 1 Worker 2 Worker 3 Worker 4 Worker 5
Master 1 Master 2 Master 3 Workers Run 5 instances of frontend:latest Run 3 instances of backend:latest Run 10 instances of analytics:latest -
Worker 1 Worker 2 Worker 3 Worker 4 Worker 5
Master 1 Master 2 Master 3 Workers Run 5 instances of frontend:latest Run 3 instances of backend:latest Run 10 instances of analytics:latest -
Worker 1 Worker 2 Worker 3 Worker 4 Worker 5
Master 1 Master 2 Master 3 Workers Run 5 instances of frontend:latest Run 3 instances of backend:latest Run 10 instances of analytics:latest analytics: 7/10 frontend: 4/5 backend: 3/3 -
Worker 1 Worker 2 Worker 3 Worker 4 Worker 5
Master 1 Master 2 Master 3 Workers Run 5 instances of frontend:latest Run 3 instances of backend:latest Run 10 instances of analytics:latest analytics: 10/10 frontend: 5/5 backend: 3/3 -
Worker 1 Worker 2 Worker 3 Worker 4 Worker 5
10.x.x.x label: analytics Services -
Worker 1 Worker 2 Worker 3 Worker 4 Worker 5
10.x.x.x label: analytics 10.x.x.x label: backend 10.x.x.x label: frontend Services -
Worker 1 Worker 2 Worker 3 Worker 4 Worker 5
10.x.x.x label: analytics 10.x.x.x label: backend 10.x.x.x label: frontend Services Internet -
Worker 1 Worker 2 Worker 3 Worker 4 Worker 5
10.x.x.x label: analytics 10.x.x.x label: backend 10.x.x.x label: frontend Cloud Load Balancer Services Internet -
Worker 1 Worker 2 Worker 3 Worker 4 Worker 5
10.x.x.x label: analytics 10.x.x.x label: backend 10.x.x.x label: frontend Cloud Load Balancer stats.example.com api.example.com example.com Services Internet -
Code I. One Codebase One codebase tracked in revision control,
many deploys II. Dependencies Explicitly declare and isolate dependencies III. Config Store config in the environment VI. Processes Execute the app as one or more stateless processes IV. Backing services Treat backing services as attached resources V. Build, release, run Strictly separate build and run stages X. Dev/prod parity Keep development, staging, and production as similar as possible VII. Port binding Export services via port binding VIII. Concurrency Scale out via the process model IX. Disposability Maximize robustness with fast startup and graceful shutdown XI. Logs Treat logs as event streams XII. Admin processes Run admin tasks as one-off processes Deploy Operate -
Code I. One Codebase One codebase tracked in revision control,
many deploys II. Dependencies Explicitly declare and isolate dependencies III. Config Store config in the environment VI. Processes Execute the app as one or more stateless processes Dockerfile Kubernetes cluster Node Pod Node Pod yaml Pod Pod -
Code I. One Codebase One codebase tracked in revision control,
many deploys II. Dependencies Explicitly declare and isolate dependencies III. Config Store config in the environment VI. Processes Execute the app as one or more stateless processes Kubernetes cluster <staging> yaml Kubernetes cluster <test> Kubernetes cluster <prod> -
Code I. One Codebase One codebase tracked in revision control,
many deploys II. Dependencies Explicitly declare and isolate dependencies III. Config Store config in the environment VI. Processes Execute the app as one or more stateless processes -
Code I. One Codebase One codebase tracked in revision control,
many deploys II. Dependencies Explicitly declare and isolate dependencies III. Config Store config in the environment VI. Processes Execute the app as one or more stateless processes fmt.Fprintf(w, "ENV: %s\n", os.Getenv("ENV")) fmt.Fprintf(w, "DB_HOST: %s \n", os.Getenv("DB_HOST")) fmt.Fprintf(w, "DB_PORT: %s \n", os.Getenv("DB_PORT")) fmt.Fprintf(w, "DB_USER: %s \n", os.Getenv("DB_USER")) fmt.Fprintf(w, "DB_PASSWORD: %s \n", os.Getenv("DB_PASSWORD" )) Application code: containers: - name: demo-app image: asatrya/alpine-k8s-pod-lb-demo env: - name: DB_HOST valueFrom: configMapKeyRef : name: demo-configmap key: DB_HOST - name: DB_PORT k8s yaml: -
Code I. One Codebase One codebase tracked in revision control,
many deploys II. Dependencies Explicitly declare and isolate dependencies III. Config Store config in the environment VI. Processes Execute the app as one or more stateless processes • Share nothing • Do not write persistent data to node memory/filesystem -
IV. Backing services Treat backing services as attached resources V.
Build, release, run Strictly separate build and run stages X. Dev/prod parity Keep development, staging, and production as similar as possible VII. Port binding Export services via port binding Deploy configMap.yaml DB_HOST=mydbhost DB_PORT=3306 Pod deployment.yaml image: imagename env: …. secret.yaml DB_USER=mydbuser DB_PASS=mydbpass Docker Registry image os.Getenv(‘DB_HOST’) os.Getenv(‘DB_PORT’) os.Getenv(‘DB_USER’) os.Getenv(‘DB_PASS’) -
IV. Backing services Treat backing services as attached resources V.
Build, release, run Strictly separate build and run stages X. Dev/prod parity Keep development, staging, and production as similar as possible VII. Port binding Export services via port binding Deploy Build image Registry Deploy & Run <staging> Deploy & Run <prod> push image (release) pull image pull image Config for staging Config for prod -
IV. Backing services Treat backing services as attached resources V.
Build, release, run Strictly separate build and run stages X. Dev/prod parity Keep development, staging, and production as similar as possible VII. Port binding Export services via port binding Deploy -
IV. Backing services Treat backing services as attached resources V.
Build, release, run Strictly separate build and run stages X. Dev/prod parity Keep development, staging, and production as similar as possible VII. Port binding Export services via port binding Deploy Node 1 NodePort Pod TargetPort Load Balancer Service Port Pod TargetPort Service Port Node 2 NodePort Pod TargetPort Service Port Pod TargetPort Service Port -
VIII. Concurrency Scale out via the process model IX. Disposability
Maximize robustness with fast startup and graceful shutdown XI. Logs Treat logs as event streams XII. Admin processes Run admin tasks as one-off processes Operate • Manual Scaling ◦ kubectl scale • Autoscaling ◦ based on CPU utilization ◦ based on custom metrics -
VIII. Concurrency Scale out via the process model IX. Disposability
Maximize robustness with fast startup and graceful shutdown XI. Logs Treat logs as event streams XII. Admin processes Run admin tasks as one-off processes Operate Service Healthy Unhealthy (Loading 45%) Liveness PASS Readiness PASS Liveness PASS Readiness FAIL -
VIII. Concurrency Scale out via the process model IX. Disposability
Maximize robustness with fast startup and graceful shutdown XI. Logs Treat logs as event streams XII. Admin processes Run admin tasks as one-off processes Operate -
VIII. Concurrency Scale out via the process model IX. Disposability
Maximize robustness with fast startup and graceful shutdown XI. Logs Treat logs as event streams XII. Admin processes Run admin tasks as one-off processes Operate • CronJob • Job -
Summary • Code: optimize for automation • Deploy: portability •
Operate: scalability, resiliency