Cloud-native .NET-Microservices mit Kubernetes @BASTAcon

Cloud-Größen wie Google, Twitter und Netflix haben die Kernbausteine ihrer Infrastruktur quelloffen verfügbar gemacht. Das Resultat aus vielen Jahren Cloud-Erfahrung ist nun frei zugänglich, und jeder kann seine eigenen Cloud-nativen Anwendungen entwickeln – Anwendungen, die in der Cloud zuverlässig laufen und fast beliebig skalieren. Die einzelnen Bausteine wachsen zu einem großen Ganzen zusammen, dem Cloud-Native-Stack. In dieser Session stellen wir die wichtigsten Konzepte und aktuellen Schlüsseltechnologien kurz vor. Anschließend implementieren wir einen einfachen Microservice mit .NET Core und Steeltoe OSS und bringen ihn zusammen mit ausgewählten Bausteinen für Service-Discovery und Konfiguration schrittweise auf einem Kubernetes-Cluster zum Laufen. @BASTAcon #BASTA17 @qaware #CloudNativeNerd

https://basta.net/microservices-services/cloud-native-net-microservices-mit-kubernetes/

Transcript

1. Mario-Leander Reimer mario-leander.reimer@qaware.de @LeanderReimer Cloud-native .NET Microservics mit Kubernetes Mainz, 28. September 2017
2. Mario-Leander Reimer Chief Technologist, QAware GmbH Contact Details Phone: +49 89 23 23 15 121 Mail: mario-leander.reimer@qaware.de Twitter: @LeanderReimer Github: https://github.com/lreimer 2 Developer & Architect 20+ years of experience #CloudNativeNerd Open Source Enthusiast QAware
3. Let‘s talk about Cloud Native Applications. 3 QAware
4. DISRUPT 4 CLOUD NATIVE APPLICATIONS INDUSTRIALIZE OPEX SAVINGS (automation & utilization) ANTIFRAGILITY HYPERSCALE TRAFFIC, DATA, FEATURES DEVOPS & CONTINUOUS DELIVERY QAware
5. BUILT AND COMPOSED AS MICROSERVICES 3 KEY PRINCIPLES 5 CLOUD NATIVE APPLICATIONS PACKAGED AND DISTRIBUTED IN CONTAINERS DYNAMICALLY EXECUTED IN THE CLOUD QAware
6. Robert A. Heinlein, 1966, The Moon Is a Harsh Mistress „There ain’t no such thing as a free lunch.“
7. 7 The 5 Cloud Commandments: 1. Everything Fails All The Time. 2. Focus on MTTR not MTTF. 3. Know the Eight Fallacies of Distributed Computing. 4. Scale out, not up. 5. Treat resources as cattle not as pets. picture alliance / United Archive
8. Design Principles for Cloud Native Applications. 8 Design for Distribution: Containers; microservices; API driven development. Design for Performance: Responsive; concurrent; resource efficient. Design for Automation: Automated Dev & Ops tasks. Design for Resiliency: Fault-tolerant and self-healing. Design for Elasticity: Scales dynamically and reacts to stimuli. Design for Delivery: Short roundtrips and automated provisioning. Design for Diagnosability: Cluster-wide logs, metrics and traces. QAware
9. Different Levels of Cloud Native Application Maturity. 9 Scales dynamically based on stimuli. Dynamic infrastructure migration without service downtime. Level 3: Cloud Native Fault tolerant and resilient design. Metrics and monitoring built-in. Runs anywhere. Infrastructure agnostic. Level 2: Cloud Resilient Consists of loosely coupled systems. Services can be found by name. Adheres to the 12-factor app principles. Level 1: Cloud Friendly No file system requirements. Runs on virtualized hardware. Executed as self-contained image. Level 0: Cloud Ready https://www.opendatacenteralliance.org/docs/architecting_cloud_aware_applications.pdf QAware
10. The Anatomy of the Cloud Native Stack. 10 How to decouple from physical hardware? How to provide the right resources for container execution? How to run (containerized) applications on a cluster? How to automate standard operations procedures? What infrastructure to provide to cloud native applications? QAware
12. Specific Cloud Native Stack with .NET Core + Steeltoe OSS and Kubernetes. QAware 12
13. (1) Microservices (2) Containerization (3) Composition (4) Orchestration The 4 Phases of Cloud Native Application Development. 13 QAware
14. Microservices
15. 15 Cloud Native Application Development: Components All Along the Software Lifecycle. DESIGN BUILD RUN § Complexity unit § Data integrity unit § Coherent and cohesive features unit § Decoupled unit § Planning unit § Team assignment unit § Knowledge unit § Development unit § Integration unit § Release unit § Deployment unit § Runtime unit (crash, slow-down, access) § Scaling unit 1:1 n:1 QAware
16. 16 Dev Components Ops Components ?:1 System Subsystems Components Services Good starting point Decomposition Trade-Offs Microservices Nanoservices Macroservices Monolith + More flexible to scale + Runtime isolation (crash, slow-down, …) + Independent releases, deployments, teams + Higher utilization possible - Distribution debt: Latency - Increasing infrastructure complexity - Increasing troubleshooting complexity - Increasing integration complexity QAware
17. A simple microservices using .NET Core and Steeltoe. 17 https://github.com/lreimer/cloud-native-basta17 QAware
18. Steeltoe OSS enables developers to implement Cloud- native .NET microservices with ease. QAware 18 Steeltoe client libraries enable .NET Core and .NET Framework apps to leverage Netflix Eureka, Hystrix, Spring Cloud Config Server, and Cloud Foundry services. Services that enable .NET and ASP.NET developers to leverage Spring Cloud: Configuration Server client Service Discovery client Hystrix Circuit Breaker Management endpoints Services that simplify using .NET and ASP.NET on Cloud Foundry: Connectors (e.g. MySql, Redis, Postgres, RabbitMQ, OAuth, etc) Configuration providers Security providers (OAuth SSO, JWT, Redis Key Ring Storage, etc.) Logging providers
19. <ItemGroup> <!-- Basic management endpoints for Cloud-native microservices --> <PackageReference Include="Steeltoe.Management.Endpoint.Info" Version="1.1.0" /> <PackageReference Include="Steeltoe.Management.Endpoint" Version="1.1.0" /> <PackageReference Include="Steeltoe.Management.Endpoint.Health" Version="1.1.0" /> </ItemGroup> // Add some health check contributors services.AddSingleton<IHealthContributor, DiskSpaceContributor>(); services.AddSingleton<IHealthContributor, ReadinessContributor>(); services.AddHealthActuator(Configuration); // Add custom info contributor services.AddSingleton<IInfoContributor, InfoContributor>(); services.AddInfoActuator(Configuration); // activate /health and /info endpoints app.UseHealthActuator(); app.UseInfoActuator(); QAware 19 Steeltoe OSS makes adding management endpoints for /health and /info really easy.
20. Containerization
21. Hardware vs. OS Virtualization. 21 Real Hardware Virtual Hardware OS OS Libraries Application Real Hardware (Virtual Hardware) OS OS Libraries Application HSI* SCI* Hardware Virtualization OS Virtualization Private Copy Shared Resources Virtual Machine Container Isolated Hardware Isolated NW-interface, process space, file system *) HSI = Hardware Software Interface SCI = System Call Interface § Less volume of private copy § Near zero runtime overhead § Short start-up time § Stong isolation QAware
22. Developer‘s Perspective of the Docker Workflow. 22 $ docker build -t cloud-native-basta17:1.0.1 . $ docker run --name cloud-native-basta17 -d \ -p 5000:5000 cloud-native-basta17:1.0.1 $ docker stop cloud-native-basta17 $ docker start cloud-native-basta17 $ docker tag cloud-native-basta17:1.0.1 \ lreimer/cloud-native-basta17:1.0.1 $ docker push lreimer/cloud-native-basta17 QAware
23. FROM microsoft/dotnet:1.1.4-runtime MAINTAINER Mario-Leander Reimer <mario-leander.reimer@qaware.de> # defined working directory and copy the published output WORKDIR /cloud-native-basta17 COPY out . # define the entry point for this container # run the application and bind to network interfaces EXPOSE 5000 ENTRYPOINT ["dotnet", "cloud-native-basta17.dll"] CMD ["--server.urls", "http://0.0.0.0:5000"] Example Dockerfile. 23 QAware
24. Some Useful Tips on using Docker. 24 A Dockerfile is code! Treat it as 1st class citizen. Know your base image. Size matters. Chain RUN commands. Use intelligent layering. Remove temporary files and directories. Define ENV variables for important parameters. Use one image for all your environments. Version your images. Use quality tools to check Dockerfiles and images. QAware
25. Composition
26. Microservices need an Ecosystem to run in. 26 How to access endpoints from the outside? How to expose and find service endpoints? How to execute an ops component? How to call other endpoints resilient and responsive? How to detect and resolve operational anomalies? How to provide cluster- wide configuration and consensus? QAware
27. 27 QAware
28. Conceptual View on Infrastructure Composition. 28 QAware
29. version: '3' services: eureka: ... config-server: ... cloud-native-basta17: build: . image: lreimer/cloud-native-basta17 environment: - EUREKA_HOST=eureka depends_on: - eureka - config-server ports: - “5000:5000" networks: - backend Example docker-compose.yml 29 $ docker-compose build $ docker-compose up –d --build $ docker-compose logs $ docker-compose down QAware
30. Orchestration
31. echo "- The default provider is GCE" export KUBERNETES_PROVIDER=gce export KUBE_GCE_ZONE=europe-west1-d export NUM_NODES=4 echo "- Another possible provider is AWS" export KUBERNETES_PROVIDER=aws export KUBE_AWS_ZONE=eu-central-1a export NODE_SIZE=t2.small curl -sS https://get.k8s.io | bash Easy K8s setup: Local, Bare Metal, Cloud or Managed. 31 QAware
32. Conceptual View on Kubernetes Building Blocks. 32 QAware
33. Services are an abstraction for a logical collection of pods. Pods are the smallest unit of compute in Kubernetes Deployments are an abstraction used to declare and update pods, RCs, … Replica Sets ensure that the desired number of pod replicas are running Labels are key/value pairs used to identify Kubernetes resources Config Maps store K/V pairs that can be passed to containers as ENV variables or as volume mounts. Most important Kubernetes concepts. 33 QAware
34. Single or Multi Container Pods? 34 QAware
35. K8s Deployment Overview. 35 QAware
36. K8s-only Deployment Variation. 36 QAware
37. apiVersion: extensions/v1beta1 kind: Deployment metadata: name: cloud-native-basta17 spec: replicas: 4 template: metadata: labels: app: cloud-native-basta17 spec: containers: - name: cloud-native-basta17 image: "lreimer/cloud-native-basta17" ports: - containerPort: 5000 env: - name: EUREKA_HOST value: eureka Example K8s Deployment Definition. 37 QAware
38. resources: # Define resources to help K8S scheduler # CPU is specified in units of cores # Memory is specified in units of bytes # required resources for a Pod to be started requests: memory: "128Mi" cpu: "250m" # the Pod will be restarted if limits are exceeded limits: memory: "192Mi" cpu: "500m" Define Resource Constraints carefully. 38 QAware
39. # container will receive requests if probe succeeds readinessProbe: httpGet: path: /admin/info port: 5000 initialDelaySeconds: 30 timeoutSeconds: 5 # container will be killed if probe fails livenessProbe: httpGet: path: /admin/health port: 5000 initialDelaySeconds: 90 timeoutSeconds: 10 Liveness and Readiness Probes for Actuator endpoints. 39 QAware
40. apiVersion: v1 kind: Service metadata: name: zwitscher-service labels: app: cloud-native-basta17 spec: # use NodePort here to be able to access the port on each node # use LoadBalancer for external load-balanced IP if supported type: NodePort ports: - port: 5000 selector: app: cloud-native-basta17 Example K8s Service Definition. 40 QAware
41. Programmable MIDI Controller. Visualizes Deployments and Pods. Scales Deployments. Supports K8s, OpenShift, DC/OS. http://github.com/qaware/kubepad/ Let‘s have some fun with K8S! 41 QAware
43. No magic! Just complex technology. 43 Building distributed systems is hard! .NET Core and Steeltoe OSS hide most of the inherent complexity. High abstraction: Boon and Bane of software development. Developers and architects need additional skills and know-how. Favour gradual transition over big bang cloud migration. QAware
44. Sources and some articles to read @ home … 44 https://github.com/lreimer/cloud-native-basta17 Der Cloud Native Stack: Mesos, Kubernetes und Spring Cloud https://goo.gl/U5cJAU Spring Cloud und Netflix OSS: Cloud-native Anwendungen bauen https://goo.gl/edNlUK Cloud-native Anwendungen mit Kubernetes
 https://goo.gl/dVkoyR Eine Einführung in Apache Mesos: Das Betriebsystem der Cloud
 https://goo.gl/7SnMZA QAware
45. QAware 45
46. Mario-Leander Reimer mario-leander.reimer@qaware.de @LeanderReimer github.com/lreimer linkedin.com/qaware slideshare.net/qaware twitter.com/qaware xing.com/qaware