SIG-Multicluster Intro and Deep Dive - Jeremy Olmsted-Thompson & Laura Lorenz, Ryan Zhang, Stephen Kitt

SIG-Multicluster Group Focus and Approach

https://multicluster.sigs.k8s.io/
The SIG MC group focuses on multiple Kubernetes clusters, addressing scenarios such as fault tolerance, data locality, policy, capacity, and performance (00:01:07).
The group's approach emphasizes end-user APIs, avoiding trying to address optional problems and maintaining consistency with existing Kubernetes APIs (00:03:23).
A core concept in multicluster is the "cluster set," representing a group of clusters governed by a single authority with a high degree of trust within the set (00:04:21).
The SIG-Multicluster is working on projects such as the "About API," which allows clusters to represent properties about themselves, and the "Multicluster Services API," which enables services to be exposed across multiple clusters (00:06:15).

https://multicluster.sigs.k8s.io/concepts/multicluster-services-api/
The MC Services API builds upon the existing service API, allowing services to be expressed across multiple clusters in a cluster set (00:08:55).
There is a V1 Alpha 2 in progress, focusing on a specific factor in the service import and how it broadcasts inherited service properties, with some backwards compatible improvements also being discussed (00:10:08).
The integration between MCS and the Gateway APIs is a hot topic, including using a service import as a backend to the Gateway API and its future evolution (00:10:31).
The concept of MCS plus Gateway allows for routing to a service across multiple clusters, described by the Gateway API (00:11:11).

https://multicluster.sigs.k8s.io/concepts/cluster-profile-api/
The problem of orchestration in a MC environment is being addressed, with a focus on APIs and guidance rather than implementations (00:11:46).
The community is working on unifying the interface for multicluster projects, with the concept of cluster infantry and the cluster profile API being developed (00:15:28).
The cluster profile API is a read-only API that reflects the properties of a cluster, as opposed to the cluster API which dictates how a cluster should be configured (00:17:02).
The cluster profile API is still in its early stages, with opportunities for the community to help steer its development (00:16:13).
The leaf clusters or workload clusters can pull work from the Hub cluster through the control plane, allowing the control plane to dictate what runs on the leaf clusters without having access to them (00:20:09).
The cluster profile API is used to tell the central controller about the cluster inventory, and it works well with the about API, which tells the cluster itself who you are and what you have (00:20:57).

The SIG is interested in defining patterns for using different tools and documenting what works well for end users, as well as addressing leader election across clusters (00:22:06).
The SIG is looking for input and involvement from the community, and there are various ways to get involved, including attending bi-weekly calls, contributing to test suites and conformance suites, and helping with documentation (00:22:51).
The SIG has a website and a slack channel where people can reach out and get involved, and there is also a mailing list that provides a calendar invite for bi-weekly calls (00:25:18).

The laws of physics and latency issues can make it difficult to have a single master group orchestrating nodes across different regions, and having multiple clusters can help reduce the impact of a single failure (00:27:53).
The SIG's work overlaps with the Fleet Products that Google Cloud Platform and Microsoft Azure are working on, and the SIG is trying to connect the dots between those downstream implementations and the things that are part of the SIG (00:29:20).
The goal is to manage all clusters across different cloud providers from one single place, allowing applications to be built without caring where the clusters are located (00:30:13).