Kubernetes SIG/Meetings/2023-02-28

From mediawiki.org

Agenda[edit]

  • Introductions for new members
    • [PF]: Search tried to recently deploy flink applications in k8s and
    • [CH]: Joined after years again, SME for k8s for Release Engineering, interested in seeing how to work more with k8s in the foundation
  • SIG administrivia:
  • Misc:
  • Topic:
    • Persistent Storage for workloads in our clusters
      • Needs
        • [LT]: ML Serve part does not currently have a need for Persistent Storage. For KubeFlow it’s a bit of an unknown, hope we don’t. Data Engineering will probably need this more. 2 possible use cases:
          • Deploying Datastores (e.g. Cassandra, etc)
          • Having storage for Spark etc other frameworks
        • [BK]: Search doesn’t have a lot of needs right now about this and moving to k8s their elasticsearch workloads is kinda blocked on the idea of the persistent storage. For now there doesn’t seem to be an actual reason to move the elasticsearch workloads on k8s
        • [TK]: If you only have 1 type of storage, then no one needs to maintain their own storage layer. In that case maybe it could make sense but the foundation is not yet in a place where such a mandate could make sense.
        • [CD]: One of the middle grounds would to have a shared service that would provide "barebones"/"lowest common denominator" storage to all teams, e.g. the shared internal swift cluster
        • [CD]: The “juice doesn’t justify the squeeze”, but it would be awesome if I could just put some data in a place of the filesystems without needing to talk to Swift or anything.
        • [JM]: We had some other needs up to now show up, e.g. some blob storage for some containers. Last time was the databases from maxmind GeoIP
      • Possible solutions
        • Some minor discussion about Ceph but we were missing key stakeholders
  • Off predefined topic:
    • [LT]: Interested in Kubernetes versioning discussion
    • [BK]: Wikimediafying discussion interesting
    • [CH]: Interest in having Harbour as a registry as it would help with some workloads, including mirror Dockerhub images to avoid the rate limiting issues that CI is starting to meet