Kubernetes SIG/Meetings/2023-12-19

Agenda:

• Introductions for new members (if any):
• SIG administrivia:
• Misc:
  • The Upstream_Helm_charts_policy was applied to the kube-state-metrics chart and adapted a bit in the process.
• Topic: Improve how we address outside k8s infrastructure from within charts (e.g. network policies)
  • [B] giving a problem statement from his pov
    • Having to replace kafka brokers was tedious because it needs replacing in puppet, waiting for puppet run (deploy host) and then deploy n applications consuming the updates list of brokers
    • Error prone because it’s usually unknown what needs to be deployed
  • Deployment-charts is the only way to deploy (by design)
  • Source of truth for “clusters” (e.g. definition of IPs for Kafka, Zookeeper, MariaDB etc.) is puppet, this is not ideal to sync to kubernetes.
  • Connection strings and network policies are rendered differently, one might not be enough to allow access. Some applications require each host in a cluster to be mentioned explicitly.
  • The current implementations (as helm modules) for this (kafka and mariadb) do take care of creating the proper network policies as well as rendering the connection string(s) required by the application/client
    • This means we still need the list of IPs/Cluster definitions on the deployment-servers somehow to be consumed by helm
    • This also means for some types of Clusters re-deployments of certain services would still be required
• Action Items:
  • Come up with a first demo of the proposed “calico network policy solution” [B]