Commandeering Kubernetes with Elixir

Commandeering Kubernetes with Elixir

The basics of extending Kubernetes using the Operator Pattern and a demo of using Bonny, the Elixir based Kubernetes Development Framework.

3a7fd46b11870137d0159e6f66d7332b?s=128

Cory O'Daniel

November 07, 2019
Tweet

Transcript

  1. Commandeering Kubernetes with Elixir

  2. Cory O’Daniel (apostrophe not required) Senior YAML Architect @ Container

    Heroes Creator of Bonny Kubernetes Development Framework @coryodaniel @coryodaniel
  3. None
  4. Why do we extend? The operator pattern allows you to

    codify the expertise of a human operator with deep knowledge of managing an application or set of services and how to react if there are problems.
  5. Why do we extend? Declarative Highly Available Databases

  6. Why do we extend?

  7. Why do we extend? On-demand database snapshots

  8. Why do we extend?

  9. Why do we extend? Generating TLS Certificates

  10. Why do we extend?

  11. Why do we extend? Creating S3 Buckets

  12. Why do we extend?

  13. The Operator pattern for extending Kubernetes • Process a chunked

    HTTP stream of add, modify, and delete events • Continually reconcile k8s resources’ state changes • Manage background tasks, processes, and state
  14. None
  15. Why Kubernetes? Service Discovery and Load Balancing NODE NODE Where

    is microservice-a.prod.svc.cluster.local NODE MASTERS
  16. Why Kubernetes? Scaling NODE NODE NODE NODE

  17. Why Kubernetes? Storage Orchestration NODE NODE NODE SSD NFS Host

    Path
  18. Why Kubernetes? Automated rollouts / rollbacks v1 NODE v1 NODE

    v1 NODE v2 v2 v2
  19. Why Kubernetes? Automated bin packing

  20. Why Kubernetes? Self-healing NODE NODE NODE

  21. Why Kubernetes? • Secret and Config Management • Single deployment

    tool/interface • Portability
  22. Kubernetes Crash Course

  23. None
  24. None
  25. Resource Attributes And Metadata

  26. Metadata as REST Path

  27. `kubectl explain pod` • 1 or more colocated docker containers

    • Acts as a “logical host” • Share volumes • Share network • Live and die as a unit
  28. `kubectl explain deployment` • Declarative management of pods ◦ Desired

    number of pod replicas ◦ Rollout Strategy ◦ Revision History
  29. `kubectl explain service` • Exposes a set of pods as

    a network service • Selects pods using labels
  30. Life of a Deployment

  31. Scheduler ETCD Master Components NODES Deployment ReplicaSet Pod API Server

    Deployment Controller ReplicaSet Controller Ctrl Manager HTTP POST HTTP GET deployment/nginx replicaset/nginx-jk1234 pod/nginx-jk1234-6963
  32. Node Components MASTERS kubelet docker TCP 8888 TCP 4269

  33. Writing a Kubernetes Operator

  34. Our first operator: Todos App Create a Custom Resource Definition

    (CRD) • Generates a REST Endpoint • Defines the fields and validations we expect
  35. Our first operator: Todos App Create a Controller • Polls

    REST endpoint • Reconciles changes in resource state
  36. Todo CRD: YAML Warning

  37. None
  38. None
  39. None
  40. Todo Resource

  41. Interacting with your Custom Resource

  42. None
  43. None
  44. None
  45. None
  46. Creating a Controller

  47. None
  48. None
  49. None
  50. None
  51. Building and Deploying an Operator

  52. None
  53. None
  54. None
  55. None
  56. None
  57. None
  58. None
  59. None
  60. Creating and Deleting Todos

  61. None
  62. None
  63. None
  64. Where do we go from here?

  65. Applications are long running, side-effect filled functions with env vars,

    flags, and config files as arguments.
  66. None
  67. None
  68. None
  69. Thanks!