Cloud Native Dojo @ IBM

2019/07/23(火)14:30 〜 17:30に実施されたCloud Native Dojo @ IBMの資料です。
by Doug Davis
1st session: Cloud Native: Everything you need to know in 80 minutes!
2nd session: Knative: The next wave for Cloud Native

Transcript

1. Agenda 14:00 The room open 14:30 - 14:40 (10min) Opening by Japan Developer Advocate team 14:40 - 16:00 (80min) Cloud Native: Everything you need to know in 80 minutes! 16:00 - 16:10 Break 16:10 - 17:20 (70min) Knative: The next wave for Cloud Native 17:20 - 17:30 (10min) Q&A , Closing 1
2. Everything You Need To Know About Containers (in 80 minutes) Doug Davis | dug@us.ibm.com | @duginabox 2
3. Agenda • Containers • Docker & Docker Images • Using Containers • Building Images • Kubernetes • Migration to Containers 3
4. What are containers? • A group of processes run in isolation • Similar to VMs but managed at the process level • All processes MUST be able to run on the shared kernel • Each container has its own set of "namespaces" (isolated view) • PID - process IDs • USER - user and group IDs • UTS - hostname and domain name • NS - mount points • NET - Network devices, stacks, ports • IPC - inter-process communications, message queues • cgroups - controls limits and monitoring of resources • Plus it gets its own root filesystem 4
5. VM vs Containers 5 Container Virtual Machine Hardware Hypervisor Virtual Machine Hardware Base OS/Kernel Container OS-specific files bins / libs App Operating System +procs bins / libs App App VS Virtual Machine Container VM ? Containers share the same base Kernel Each VM has its own OS App, bins/libs/OS must all be runnable on the shared kernel If OS files aren't needed they can be excluded.
6. Why Containers? • Fast startup time - only takes milliseconds to: • Create a new directory • Lay-down the container's filesystem • Setup the networks, mounts, ... • Start the process • Better resource utilization • Can fit far more containers than VMs into a host 6
7. What is Docker? • Tooling to manage containers • Containers are not new • Docker just made them easy to use • Docker creates and manages the lifecycle of containers • Setup filesystem • CRUD container • Setup networks • Setup volumes / mounts • Create: start new process telling OS to run it in isolation 7
8. Our first container $ docker run ubuntu echo Hello World Hello World • What happened? • Docker created a directory with a "ubuntu" filesystem (image) • Docker created a new set of namespaces • Ran a new process: echo Hello World • Using those namespaces to isolate it from other processes • Using that new directory as the "root" of the filesystem (chroot) • That's it! • Notice as a user I never installed "ubuntu" 8
9. ssh-ing into a container - faking it $ docker run -ti ubuntu bash root@62deec4411da:/# pwd / root@62deec4411da:/# exit $ • Now the process is "bash" instead of "echo" • But its still just a process • Look around, mess around, its totally isolated • rm /etc/passwd – no worries! • MAKE SURE YOU'RE IN A CONTAINER! 9
10. A look under the covers $ docker run ubuntu ps -ef UID PID PPID C STIME TTY TIME CMD root 1 0 0 14:33 ? 00:00:00 ps -ef • Things to notice • Each container only sees its own process(es) • Running as "root" • Running as PID 1 10
11. Docker Images • Tar file containing a container's filesystem + metadata • For sharing and redistribution • Global/public registry for sharing: DockerHub • Similar, in concept, to a VM image 11 Docker Host Containers Base OS/Kernel Containers Docker Engine Images Liberty Ubuntu
12. Docker Special Sauce • But first, let's compare VMs and Containers one more time... 12
13. VM vs Container: Notice the layers 13 Container Virtual Machine Hardware Hypervisor Virtual Machine Hardware Base OS/Kernel + procs Container OS-specific files bins / libs App Operating System +procs bins / libs App App VS Virtual Machine Container Containers share the same base Kernel Each VM has its own OS A layer A layer A layer
14. Shared / Layered / Union Filesystem • Docker uses a copy-on-write (union) filesystem • New files(& edits) are only visible to current/above layers • Layers allow for reuse • More containers per host • Faster start-up/download time • Images • Tarball of layers • Think: Transparencies on projector 14 Filesystem Fedora Ubuntu tomcat tomcat liberty CNTR1 CNTR2 CNTR3 CNTR4 app1 app2 app4 app3 Layer Layer Layer
15. Docker Registry • Creating and reusing images is only part of the story • Sharing them is the other • DockerHub - http://hub.docker.com • Public registry of Docker Images • Hosted by Docker Inc. • Free for public images, pay for private ones (one free private) • By default docker engines will look in DockerHub for images • Browser interface for searching, descriptions of images 15 Docker Host Containers Base OS/Kernel Containers Docker Engine Registry Images Liberty Ubuntu mysql nginx Liberty Ubuntu
16. Docker Component Overview 16 • Docker Engine • Manages containers on a host • Accepts requests from clients • REST API • Maps container ports to host ports • E.g. 80 à 3582 • Images • Docker Client • Drives engine • Drives "builder" of Images • Docker Registry • Image DB Docker Host Containers Base OS/Kernel Containers Docker Engine $ docker run ... $ docker build ... Registry Exposed/Mapped Ports Images Liberty Ubuntu mysql nginx Liberty Ubuntu Client
17. Docker Summary • Docker is just a tool to manage containers • Key concepts: Containers, Docker Engine, Images, Registries • Docker value-add: • An excellent User Experience • Image Layers • Easily shared images via DockerHub • Why? When compared to VMs: • Better resource utilization - CPU, Memory, Disk • Faster start-up times • Easier tooling/scripting via Docker CLI 17 Applies to containers in general!
18. Using Containers • Containers are ephemeral & stateless • State is kept outside of the container • Volume mount into the container • External storage - e.g. cloud object storage, DB • Monitoring • Tools to monitor resource usage of container • Can limit resources allocated to each container to prevent excessive usage • Logging & Monitoring • Typically stdout/stderr of container is the log • Can leverage tooling and external services for capturing logs or metrics 18
19. What are they good for? • Just about everything • Servers, services - e.g. webapps, front-ends for back-end system • Pre-built environments - e.g. testing • Anything you don't want to install locally - e.g. compilers, runtimes • If you don't need to modify the kernel, start with containers 19
20. Demo $ docker-demo 20
21. Building Images • Reminder: Images are just snapshots of a filesystem + metadata • No runtime state is kept in the Image • Many tools available - e.g. "docker build" + Dockerfiles $ cat Dockerfile FROM golang COPY myapp.go / RUN go build -o /myapp /myapp.go FROM ubuntu COPY --from=0 /maypp /myapp ENTRYPOINT [ "/myapp" ] $ docker build -t myapp . $ docker run myapp 21
22. Container Orchestration • Single container management is relatively easy • Managing clusters of containers is a challenge • Networking • Between containers and external • Load-balancing • Security & Isolation • Scaling - e.g. based on load • Lifecycle management - e.g. restart if crashed • Placement to ensure high availability 22
23. Kubernetes • Container Orchestrator • Provision, manage, scale applications • Manage infrastructure resources needed by applications • Volumes • Networks • Secrets • And many many many more... • Declarative model • Provide the "desired state" and Kubernetes will make it happen • What's in a name? • Kubernetes (K8s/Kube): "Helmsman" in ancient Greek 23
24. Kubernetes Architecture • At its core, Kubernetes is a database (etcd). With "controllers" that react to changes in the DB. The controllers are what make it Kubernetes. This pluggability and extensibility is part of its "secret sauce". • DB represents the user's desired state • Controllers attempt to make reality match the desired state "API Server" is the HTTP/REST front-end to the DB More on controllers later... 24 DB API Server Client/User Controller Node Networks Volumes Secrets ... Request Monitor
25. Kubernetes Resource Model • Config Maps • Daemon Sets • Deployments • Events • Endpoints • Ingress • Jobs • Nodes • Namespaces • Pods • Persistent Volumes • Replica Sets • Secrets • Service Accounts • Services • Stateful Sets, and more... • Kubernetes aims to have the building blocks on which you build a cloud native platform. • Therefore, the internal resource model is the same as the end user resource model. Key Resources • Pod: set of co-located containers • Smallest unit of deployment • Several types of resources to help manage them • Replica Sets, Deployments, Stateful Sets, ... • Services • Define how to expose your app as a DNS entry • Query based selector to choose which pods apply 25 • A resource for every purpose
26. Sample Resource YAML 26 $ kubectl apply -f pod.yaml Less user-friendly than Docker's CLI apiVersion: apps/v1 kind: Deployment metadata: name: httpd-rs spec: replicas: 2 selector: matchLabels: app: httpd-app template: metadata: labels: app: httpd-app spec: containers: - name: httpd image: ibmdojo/httpd Pod YAML: apiVersion: v1 kind: Pod metadata: name: httpd-pod spec: containers: - name: httpd image: ibmdojo/httpd
27. Kubernetes In Action 27 1. User via "kubectl" deploys a new application 2. API server receives the request and stores it in the DB (etcd) 3. Controllers detect the resource changes and act upon it 4. Deployment controller detects the new app and creates new pods in the DB to matchthe desired # of instances 5. Scheduler assigns new pods to a kubelet 6. Kubelet detects pods and deploys them via the container runtime (e.g. Docker) 7. Kubeproxy manages network traffic for the pods – including service discovery and load-balancing Node Node Pod Base OS/Kernel Docker Engine Images Liberty Ubuntu Kublet Kube- Proxy Pod/Service C C C Master API Server Controllers Replication Endpoints ... Kub Client ( kubectl ) deployment.yml Storage (etcd) 7 1 2 3 4 6 Scheduler 5
28. Demo $ kube-demo 28
29. Kubernetes - Summary • Container Orchestration • Most popular in the community • Most major Cloud Native players are there • Lots of tooling to help with deploying/managing K8s and your apps • https://kubernetes.io • https://github.com/kubernetes • IBM Kubernetes Service: https://ibm.com/iks 29
30. Migrating to Containers / Modernizing your application • Build new cloud native apps • Breakdown monolith into microservices • Extend existing monolith using containers • Lift and Shift - to containers or VMs • Replace existing features with SaaS offerings • Leverage DevOps - CI/CD best practices 30
31. More & IBM IKS • Education : https://developer.ibm.com/ • Hands-on tutorials : https://github.com/IBM/containers • Docker 101 • Kubernetes 101 • Local Kubernetes Development • Helm 101 • Kubernetes Networking 101 • Istio 101 • Service Catalog • Knative 101 • IBM Kubernetes Service (IKS) : https://ibm.com/iks • Can get a free cluster to play with 31
32. Break 32
33. Knative- A New Way To Kube Doug Davis STSM - OM Knative dug@us.ibm.com @duginabox
34. Agenda A bit of history... then some Knative... a demo!
35. In the beginning there was Docker, and it was good... $ docker run ubuntu echo Hello World Hello World o Containers o Build / Images o DockerHub
36. Then we started to mature, doing real work... o Networks o Volumes o Services o Swarm / SwarmKit
37. Adulting Kubernetes! Enterprise grade environment for deploying containerized applications. Enhancing developer productivity, resource efficiency, automated operations, and open source flexibility to accelerate your time to market. C-Suite Definition
38. The Claim: Kubernetes is for Developers Deploy and manage your containerized applications
39. Reality: What really is Kubernetes? A RESTful DB with a set of watchers that react to changes in the DB Blue/green deployments Containers Pods Replica Sets Deployments Services Endpoints Secrets Networks Volumes/PV/PVC Ingress / LBs yaml Spec vs Status helm kubectl Istio ...
40. Back to first principles What was Kubernetes supposed to be? - A platform to build platforms Reality: It is the platform - Force developers to manage infrastructure - With flexibility came complexity I just want to run my app!
41. Enter stage left... Serverless Increasing focus on business logic Decreasing concern (and control) over infrastructure implementation Virtual machines Functions Containers Bare Metal • Faster start-up times • Better resource utilization • Finer-grained management • Splitting up the monolith
42. Properties of Serverless • Stateless • Event Driven • Auto-scaled / Scale-to-zero • Short Lived • Reduced Cost • Faster Time to Market
43. Introducing Knative "Knative extends Kubernetes to provide a set of middleware components that are essential to build modern, source-centric, and container- based applications that can run anywhere: on premises, in the cloud, or even in a third-party data center." - Kn docs Huh ?
44. What it really means... • An opinionated and simplified view of application management • Heavily influenced by Serverless • Allowing developers to focus on coding • New Kubernetes extension resources (CRDs)
45. Technical Details 3 Main Components • Serving is the runtime component • Eventing for loosely coupled services • Client for simplified UX to Kubernetes
46. Knative Serving Manages the hosting aspects of your app • Service - manages the lifecycle of app • Configuration - manage history of app • Revision - A snapshot of your app • Config and image • Route - Endpoint and network traffic management Route Configuration Revision 1 Revision 2 Revision 3 90% 10% Service
47. Knative Serving - What it really means... o Manages the core K8s resources for you o Provide a nicer UX for K8s o Enables easy traffic splitting - e.g. for A/B upgrades o Better resource utilization o Scale to zero capabilities o Auto-scaling on demand o Runtime building blocks on which Cloud Providers can build a Serverless platform
48. Knative Eventing Eventing Primitives o Event Source - connect to event producer o Can create the subscription for you o Brokers - a receiver of events o E.g. a queue o Trigger - ask for events from a Broker o Can specify a filter Manage to coordination/delivery of events to sinks Service Trigger ?? Broker Source Replies Sink Svc/Chan
49. Knative Eventing - Newer Things o Sequence o Ordered set of "Sinks" o Final "Reply" o Event Registry o Collection of EventTypes (Kn Broker, CloudEvent type/source/schema) o Auto registration by some EventSources (when sink is a broker)
50. Knative Client - kn kn [ noun ] [ verb ] [ args ] Services : Create, Delete, Describe, List, Update Revisions : Describe, Delete, List Routes : List WIP Plug-ins to extend list of commands Service Traffic splitting Integration with KnEventing
51. Knative Build Build container images from source • Built from your source control system • Customizable BuildTemplates define the build steps/process • Results are stored in a container registry
52. Tekton Not a Knative project but derived from Knative Build Task : set of "steps" : execution of a container TaskRun : resource representing the execution of a Task Pipeline : ordered set of "tasks" PipelineRun : resource representing the execution of a Pipeline Exercise for the user to connect Tekton to KnServing https://github.com/tektoncd/pipeline
53. Tekton - Example apiVersion: tekton.dev/v1alpha1 kind: TaskRun metadata: generateName: build-hello spec: serviceAccount: build-bot taskSpec: inputs: resources: - name: source type: git steps: - name: build-and-push workingdir: /workspace/source image: gcr.io/kaniko-project/executor env: - name: DOCKER_CONFIG value: /builder/home/.docker command: - /kaniko/executor - --dockerfile=./Dockerfile - --context=/workspace/source/ - --destination=index.docker.io/... inputs: resources: - name: source resourceSpec: type: git params: - name: url value: https://github.com/...
54. Demo time
55. Kubernetes Cluster Knative Demo Github Source Kn Service Revision v2 Revision v1 Route Kn API App Developer Config Tekton Build Image Repo Rebuild Svc Build Trigger App – v1 Istio Gateway App User App – v2 Builder Pod Github Repo Event Push Update Trigger
56. Demo Summary What we did: Serving: o Deployed several revision of an app o Each deployment did a rolling upgrade o Traffic split between revisions Eventing o Integrated Github webhook - subscribed o "push" events on our repo sent to a rebuild KnService Tekton o Invoked via rebuild KnService o Built new image, pushed to DockerHub o Triggered new revision of our app https://github.com/duglin/helloworld What we didn't do: o Create Deployment / ReplicaSet o Create a K8s Service o Create an Endpoint / Ingress o Set up a dynamic Load-Balancer o Set up an auto-scaler o Talk to Github directly to create web hook o ...
57. Knative: A Rose By Any Other Name... What is Knative? • Serverless Framework? • PaaS? • New "Deployment" w/ magic pixie dust? • A new Kubernetes user experience? Does it matter? Does it meet your needs? Letting developers be developers again
58. Knative - Technical Notes o Not full Pod support (yet) o Can use Istio for networking/traffic splitting o But it is optional o "kn" CLI is the preferred UX when not using yaml o Service vs Configs/Revisions/Routes o Consider Tekton for your CI/CD needs
59. Managed Knative on IKS - Experimental o Managed Knative add-on for IBM Cloud Kubernetes Service (IKS) - "experimental" o One click install of Knative into your cluster o Includes Istio o Updates to Knative are managed o https://ibm.com/iks $ ic ks cluster-addon-enable knative -y CLUSTER
60. IBM Developer / © 2019 IBM Corporation 60 • Knative: https://github.com/knative/docs/ • IKS: https://ibm.com/iks • Demo: https://github.com/duglin/helloworld Thank You!