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

[JNATION 2021] Kubernetes & Co, beyond the hype: 10 tips for designers who want to create cloud native apps

[JNATION 2021] Kubernetes & Co, beyond the hype: 10 tips for designers who want to create cloud native apps

Kubernetes and cloud technologies are nowadays the new standard to deploy different cloud native applications: api, batchs, microservices and ... monoliths!
These technologies help to solve many issues but with some complexity.
It could be difficult for developers and designers to identify the constraints of such architectures.

In this presentation, you will (re)discover ten tips and pieces of advice I applied and found useful in my last JAVA projects (Spring, JEE).

I will talk about:

Application ecosystem
Choice of technical solutions
K8S design constraints
And more!

Alexandre Touret

October 28, 2021

More Decks by Alexandre Touret

Other Decks in Programming


  1. Kubernetes & Co, beyond the hype 10 tips for designers

    who want to create cloud native apps
  2. 4

  3. What are the NFRs? Do you have constraining SLOs? (eg.

    >99% SLA availability) Does your system need to be dynamically scaled? 8
  4. Providing « on demand » environments 9 Do you need

    to deliver environments on demand (and really fast)?
  5. 11

  6. 13

  7. «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
  8. 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
  9. 21

  10. 23

  11. 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
  12. 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
  13. 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
  14. 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(); } } [...] }
  15. 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
  16. 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
  17. 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
  18. 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
  19. What about configuration files? We can specify them as variables

    in config maps We can also externalize them 40
  20. 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 }}
  21. Externalize values apiVersion: autoscaling/v1 kind: HorizontalPodAutoscaler metadata: labels: [...] spec:

    maxReplicas: {{ .Values.myapp.maxReplicaCount }} minReplicas: {{ .Values.myapp.minReplicaCount }} [...] targetCPUUtilizationPercentage: {{ .Values.myapp.replicationThreesold }} 42
  22. File templates apiVersion: v1 kind: ConfigMap metadata: name: configuration labels:

    [...] data: application.properties: |- {{ tpl (.Files.Get "conf/application.properties") . | nindent 4}} 44
  23. 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
  24. 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
  25. 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
  26. Distributed tracing You can identify and correlate your API calls

    on your microservices based architecture by implement Opentracing 52
  27. 53