Kubernetes & Co, beyond the hype 10 tips for designers who want to create cloud native apps

Alexandre Touret Architect / Developer #Java #API #CI #Cloud #Software_Craftsmanship 2 @touret_alex https://blog.touret.info

Some context... 1.

4

Used technologies 5

Do you REALLY need it?

Small business application Controlled scope Automatized deployments already implemented 7

What are the NFRs? Do you have constraining SLOs? (eg. >99% SLA availability) Does your system need to be dynamically scaled? 8

Providing « on demand » environments 9 Do you need to deliver environments on demand (and really fast)?

Docker & Cie basics

11

You will have to know… 12

13

Organization

«Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.» — M. Conway 15

What’s the associated RACI ? Is your organisation compatible? 16 RACI & Responsabilies

The stateless apps and the others…

18 Codebase One codebase tracked in revision control, many deploys Dependencies Explicitly declare and isolate dependencies Config Store config in the environment Backing Services Treat backing services as attached resources Build, release, run Strictly separate build and run stages Backing Services Treat backing services as attached resources Processes Execute the app as one or more stateless processes Port Binding Export services via port binding Disposability Maximize robustness with fast startup and graceful shutdown Dev/prod parity Keep development, staging, and production as similar as possible Logs Treat logs as event streams Admin processes Run admin/management tasks as one-off processes Source: https://12factors.net

19 For an API

(Fast) application startup

21

Choose wisely your frameworks and target runtime platforms

23

24 Items to check ✓ Fast startup ✓ Shutdown handling ✓ Ability to be integrated into Docker and K8S ✓ Observability ✓ Memory and CPU consumption ✓ Dependency and patch management

TOMCAT vs FAT JARS → Production – Development teams trade-off 25

Observability

Address this point from design phase Don’t wait for the production deployment Expose your system status through endpoints Be careful to the used FRAMEWORKS 27

liveness & readiness probes livenessProbe: failureThreshold: 3 httpGet: path: /actuator/health/liveness port: http scheme: HTTP initialDelaySeconds: 30 periodSeconds: 10 successThreshold: 1 timeoutSeconds: 1 28 readinessProbe: failureThreshold: 3 httpGet: path: /actuator/health/readiness port: http scheme: HTTP initialDelaySeconds: 30 periodSeconds: 30 successThreshold: 1 timeoutSeconds: 1

Spring Actuator management.health.probes.enabled=true management.endpoints.enabled-by-default=true management.health.livenessstate.enabled=true management.health.readinessstate.enabled=true management.endpoint.health.show-details=always management.endpoint.health.probes.enabled=true management.endpoint.health.enabled=true LivenessStateHealthIndicator & ReadinessStateHealthIndicator 29

30 @Component public class MongoDBActuatorHealthIndicator implements HealthIndicator { [...] @Override public Health health() { // ping database } @Override public Health getHealth(boolean includeDetails) { if (!includeDetails) { return health(); } else { var statuses = mongoDBHealthService.findStatusForAllConfigurations(); return Health.status(checkStatus(statuses)).withDetails(statuses).build(); } } [...] }

Monitoring ▪ Micrometer ▪ Prometheus ▪ Grafana 31

32 management: endpoints: enabled-by-default: true web: exposure: include: '*' jmx: exposure: include: '*' endpoint: health: show-details: always enabled: true probes: enabled: true shutdown: enabled: true prometheus: enabled: true metrics: enabled: true health: livenessstate: enabled: true readinessstate: enabled: true datasource: enabled: true metrics: web: client: request: autotime: enabled: true Actuator configuration Metrics configuration

No content

Steps to integrate in your CI/CD pipeline ✓ Unit and integration tests ✓ Docker image creation ✓ Created docker image “Smoke tests” ✓ Continuous deployment of your develop branch ✓ HELM charts deployment ✓ Release deployment ✓ ... 34

Example Spring Boot, Tomcat, JDK Migration Tested locally → Dev → Staging ⇒ In one day 35

Configuration

37 ▪ Environment variables ▪ Config Maps ▪ Secrets

Environment variables spec: containers: - env: - name: JAVA_OPTS value: >- -XX:+UseContainerSupport -XX:MaxRAMPercentage=70.0 -Dfile.encoding=UTF-8 - Djava.security.egd=file:/dev/./urandom 38

Config maps apiVersion: v1 kind: ConfigMap metadata: creationTimestamp: 2021-03-11T18:38:34Z name: my-config-map [...] data: JAVA_OPTS: >- -XX:+UseContainerSupport -XX:MaxRAMPercentage=70.0 -Dfile.encoding=UTF-8 -Djava.security.egd=file:/dev/./urandom 39

What about configuration files? We can specify them as variables in config maps We can also externalize them 40

Files in config maps volumeMounts: - mountPath: /config name: configuration-volume readOnly: true [...] volumes: - configMap: defaultMode: 420 name: configuration name: configuration-volume 41 apiVersion: v1 kind: ConfigMap [...] data: my.conf: {{- (.Files.Glob "conf/*").AsConfig | nindent 2 }}

Externalize values apiVersion: autoscaling/v1 kind: HorizontalPodAutoscaler metadata: labels: [...] spec: maxReplicas: {{ .Values.myapp.maxReplicaCount }} minReplicas: {{ .Values.myapp.minReplicaCount }} [...] targetCPUUtilizationPercentage: {{ .Values.myapp.replicationThreesold }} 42

Values.yml myapp: minReplicaCount: "2" maxReplicaCount: "6" replicationThreesold: 80 43

File templates apiVersion: v1 kind: ConfigMap metadata: name: configuration labels: [...] data: application.properties: |- {{ tpl (.Files.Get "conf/application.properties") . | nindent 4}} 44

Templates application.properties file logging.level.org.hibernate.stat={{ .Values.configmap.application.org_hib ernate_stat }} logging.level.org.springframework.sec urity={{ .Values.configmap.application.org_spr ingframework_security }} 45 values.yml file configmap: application: org_hibernate_stat: ERROR org_springframework_security: ERROR

Binary files apiVersion: v1 # Definition of secrets kind: Secret [...] type: Opaque # Inclusion of binary configuration files data: my_keystore.jks: {{ .Files.Get "secrets/my_keystore.jks" | b64enc }} 46

Efficiently logging

Log management In the console: kubectl logs --tail Logs aggregator (ex. ELK) 48

Docker containers output stream stdout & stderr It’s useless to setup a file output stream 49

Best practices Indicate in your LOGS: Container informations (image name, container ID,…) Kubernetes related informations (POD @IP, POD ID, namespace,...) Log4j Docker Support – Log4j Kubernetes Support 50

To go further You can identify the related informations of the APIs calls: Caller ID, Correlation ID, request data,… zalando/logbook: An extensible Java library for HTTP request and response logging 51

Distributed tracing You can identify and correlate your API calls on your microservices based architecture by implement Opentracing 52

53

Thanks! Any question? 54