Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Jax London 2019 - Serverless On Your Own Terms using Knative

Jax London 2019 - Serverless On Your Own Terms using Knative

Knative is an open-source serverless platform extending Kubernetes to help developers build, deploy, and manage modern serverless workloads. Whether you write functions or applications Knative solves many of the common developer burdens like scaling, resource and route management, or logging and tracing without the need to worry about the underlying infrastructure. Knative also comes with a vibrant ecosystem of multi-cloud event sources which are easy to wire up in your application and trigger your code. And because Kantive is open, you can run it on any Cloud or in your own datacenter where Kubernetes is offered. This session will provide overview of Knative project and introduce many of the common developer and operational patterns used to run real-world solutions.

In this session you will:
* Learn what Knative is and what are its benefits
* Overview major Knative components and their role
* Use demos to illustrate common way to interact with Knative

Mark Chmarny

October 08, 2019
Tweet

More Decks by Mark Chmarny

Other Decks in Technology

Transcript

  1. Operator No Infra Management Managed Security Pay only for usage

    Service-based Event-driven Open Serverless Models Developer
  2. .js .rb .go .py .sh … 0 1 0 1

    0 0 1 1 1 Containers • Any Language, Library, Binary • Granular version control • Ecosystem of base images Common unit of workload description (Dockerfile) and delivery (Container Image)
  3. Portability Kubernetes Offered by virtually all Cloud Service Providers Knative

    Codifies serverless, broad contributor/user community Tekton Kubernetes-native [build] pipeline, industry leading CI/CD partners
  4. Knative Today Products Google Cloud Run Red Hat OpenShift SAP

    Kyma Google Cloud Run on GKE IBM Cloud Kubernetes Service TriggerMesh Build Tekton Serving Kubernetes Platform Primitives Events ...
  5. Knative Serving Functionality • Activates/scales workload based on request (up/down

    to 0 pods) • Manages revision code/config (update, rollback, split traffic) • Request path/services access control (manage service mesh) • Granular metrics/logging, Custom domains, TLS support... Integration • Connect with other services like GCP Cloud Build and Stackdriver • Extend with partner integrations like Solo.io, GitLab, Datadog
  6. Knative Eventing Functionality • Orchestrates on/off cluster event sources •

    Declaratively binds importers, brokers, triggers, and services • Scales from just few events to live streaming pipelines • Uses standard CloudEvents (CNCF Project) Integration • Use existing event sources available or build your own (e.g. Apache Camel, AWS SQS, GCP PubSub) • Plugable channel provisioners (e.g. PubSub. Kafka, NATS, In-Memory)
  7. Knative Community 60+ Contributing Companies >7K Pull Requests ~450 Individual

    Contributors 9 Working Groups v0.9 Predictable Releases source: knative.teststats.cncf.io/d/8/dashboards
  8. # latest releases docs: # https://knative.dev/docs/install/ $ kubectl apply \

    -f https://github.com/knative/serving/releases/.../serving.yaml \ -f https://github.com/knative/eventing/releases/.../eventing.yaml \ -f https://github.com/knative/monitoring/releases/.../monitoring.yaml Install
  9. Install $ gcloud beta container \ clusters create my-cluster \

    --addons CloudRun Also available for: • AKS • Docker • Gardener • IKS • Minikube • OpenShift/Minishift • PCS Quick start: bit.ly/cr-gke
  10. Config $: kubectl get ns NAME STATUS default Active istio-system

    Active knative-eventing Active knative-monitoring Active knative-serving Active knative-sources Active kube-public Active kube-system Active $: kubectl get cm -n knative-serving NAME DATA config-autoscaler 1 config-defaults 1 config-deployment 2 config-domain 1 config-gc 1 config-istio 1 config-logging 1 config-network 6 config-observability 1 config-tracing 1
  11. Deployment (CLI) # Knative Client: # github.com/knative/client kn service create

    my-service \ --image registry/image-name # Result: # my-service.namespace.domain.dev
  12. Deployment (YAML) kubectl apply -f service.yaml # simple-service.yaml apiVersion: serving.knative.dev/v1

    kind: Service metadata: name: service-name spec: template: spec: containers: - image: registry/image-name
  13. Local build/push using Dockerfile docker build -t user/app:version; docker push

    ... Build Service (Cloud Build, GitHub Actions, GitLab, Jenkins…) git tag ...; git push origin ...; # Cloud Build: github.com/mchmarny/maxprime On-cluster Build using Tekton Pipelines kubectl apply -f task.yaml # Maven (tekton-jib-build): github.com/mchmarny/knative-demos ko, quick iteration, no Dockerfile, golang only ko apply -f config.yaml github.com/google/ko Build Options (╯°□°)╯︵ ┬─┬
  14. Kf (Knative + Cloud Foundry) Knative Tekton Kf Feels like

    Cloud Foundry Runs on Kubernetes Powered by Knative Supports logs, buildpacks, app manifests, routing, service brokers, and injected services… all on Kubernetes using Knative, Istio, and Tekton. github.com/google/kf
  15. Knative Serving Usage Patterns Public Service • Website • API

    endpoint Internal Service • Backing Microservices • Eventing Targets • Mobile backend • Webhook
  16. Request Path Kubernetes Cluster Knative Logo Service Vision API User

    HTTPS HTTPS curl -H "Content-Type: application/json" \ -d '{"id":"test","url":"https://storage.googleapis.com/kdemo-logos/google.png"}' \ https://logo.demo.knative.tech/
  17. Request Path Kubernetes Cluster Knative Frontend UI Logo Service User

    Service Vision API Firestore API User HTTPS demo OAuth HTTPS HTTPS
  18. Request Path Kubernetes Cluster Knative Frontend UI Logo Service User

    Service Vision API Firestore API User HTTPS demo OAuth HTTPS HTTPS
  19. Request Path Kubernetes Cluster Knative Frontend UI Internal Logo Service

    Internal User Service Vision API Firestore API User HTTPS demo OAuth HTTPS HTTPS
  20. Knative Object Model Revision 1 Revision 2 Revision 3 Configuration

    Route Service Route - named endpoint and a mechanism for routing traffic Revisions - immutable snapshots of code + config Configuration - stream of environments for Revisions Service - top-level wrapper for managing Route/Configurations sets
  21. # List current revisions in the namespace (filter on service

    name) kubectl get revisions -n demo -l serving.knative.dev/service=maxprime NAME SERVICE NAME GENERATION READY maxprime-vq25k maxprime-vq25k-service 3 True maxprime-wtz1g maxprime-wtz1g-service 2 True maxprime-qtz5p maxprime-qtz5p-service 1 True # Edit revision in service traffic section # (status/traffic[n]/revisionName) kubectl edit ksvc maxprime -n demo Simple Revision Management
  22. Blue/Green Revision Management Traffic Live Service Traffic # Initial state

    # Spin up “Blue” # version with # new code/features Live Service Traffic # Shift traffic over # from “Green” version # to new “Blue” version New Revision Live Service Old Revision (or Rollback)
  23. apiVersion: serving.knative.dev/v1 kind: Service metadata: name: bg namespace: demo spec:

    template: spec: containers: - image: gcr.io/knative-samples/knative-route-demo Blue/Green (deployment) Service 100% Revision Source: github.com/mchmarny/knative-demos
  24. spec: template: metadata: name: bg-2 ... traffic: - tag: current

    revisionName: bg-1 percent: 100 - tag: candidate revisionName: bg-2 percent: 0 - tag: latest latest Revision: true percent: 0 Blue/Green (update) Service Revision (bg-2) Revision (bg-1) 0% - bg-candidate.demo.knative.tech 100% - bg.demo.knative.tech
  25. ... traffic: - tag: current revisionName: bg-1 percent: 50 -

    tag: candidate revisionName: bg-2 percent: 50 - tag: latest latest Revision: true percent: 0 Blue/Green (traffic split) Service Revision (bg-1) Revision (bg-2) 90% 80% 70% 60% 50% 40% 60% 50% 40% 30% 20% 10%
  26. ... traffic: - tag: previous revisionName: bg-1 percent: 100 -

    tag: current revisionName: bg-2 percent: 0 - tag: latest latestRevision: true percent: 0 Blue/Green (rollback) Service Revision (bg-1) Revision (bg-2) 100% 0%
  27. gcloud alpha run services set-traffic maxprime \ --to-revision maxprime-v1=90,maxprime-v2=10 #

    Split traffic # across multiple # revisions Simpler Traffic Management source: github.com/mchmarny/ab-test-demo
  28. Name Description Apache Camel Allows to use Apache Camel components

    for pushing events into Knative Apache Kafka Brings Apache Kafka messages into Knative AWS SQS Brings AWS Simple Queue Service messages into Knative Cron Job Uses an in-memory timer to produce events on the specified Cron schedule. GCP PubSub Brings GCP PubSub messages into Knative GitHub Brings GitHub organization/repository events into Knative GitLab Brings GitLab repository events into Knative. Google Cloud Scheduler Google Cloud Scheduler events in Knative when jobs are triggered Google Cloud Storage Brings Google Cloud Storage bucket/object events into Knative Kubernetes Brings Kubernetes cluster/infrastructure events into Knative source: https://github.com/knative/docs/tree/master/docs/eventing/sources Knative Event Importers (aka Sources)
  29. CloudEvents { "specversion": "0.2", "type": "com.github.pull.create", "source": "https://github.com/cloudevents/spec/pull/123", "id": "A234-1234-1234",

    "time": "2019-04-08T17:31:00Z", "datacontenttype": "application/json", "data": "{ GitHub Payload... }" } FTP GitHub GCS Broker FTP Event Importer GitHub Event Importer GCS Event Importer CloudEvent
  30. Namespace subscribe Trigger Service (Callable) Broker Trigger Service (Callable) subscribe

    filter= filter= Importer Events Importer Events ingress ingress publish ✓ ✓ ✓ Knative Eventing Objects
  31. Knative Event Broker apiVersion: eventing.knative.dev/v1alpha1 kind: Broker metadata: name: b1

    namespace: demo spec: {} status: address: hostname: b1-broker.demo.svc.cluster.local Simple Broker - 1-n per NS by default - Discoverable endpoint - Manages • Channels • Ingress filter/policy
  32. Knative Event Trigger apiVersion: eventing.knative.dev/v1alpha1 kind: Trigger metadata: name: build-status-slack-notifier

    spec: filter: sourceAndType: type: com.google.build.status subscriber: ref: apiVersion: serving.knative.dev/v1 kind: Service name: slack-sender Simple Trigger - Uses CloudEvents - Supports Filtering - Can produce new events Build status Slack notifications demo: https://github.com/mchmarny/knative-build-status-notifs
  33. Eventing Pipeline Twitter Event Importer query: knative type: com.twitter Broker

    (default) Trigger type filter: com.twitter .negative Slack Publishing Service Slack Channel (#twitterback) Trigger type filter: com.twitter Sentiment Scoring Service Trigger type filter: com.twitter Event Store Service FireStore Collection knative-tweets Trigger type filter: com.twitter. positive Event Viewer (WebSocket) 1. Save all tweets for reference 2. Classify tweets based on sentiment 4. Send negative to Slack for review 5. Display positive tweets in UI 1 2 4 5 bit.ly/kn-tw-event Natural Language API replay Trigger type filter: com.twitter .noneng Sentiment Scoring Service 3. Translate non-English tweets 3 Translation API
  34. * Cron job importer to wire up weekly report *

    Process IoT Core events * GCP PubSub (connector to many other GCP event sources) * Actuate on Kubernetes events (beyond webhook) * Declarative GitHub webhook processing ... # samples bit.ly/kn-event-samples Knative Eventing Use-cases
  35. Docs, Blog, Community knative.dev Quick Start bit.ly/cr-gke Source & Samples

    github.com/knative Questions? slack.knative.dev Anything else @mchmarny