what's baking

[olga-mir]

Experiments:

• deploy script is a series of 'apply & wait' logic. if flux is installed on temp bootstrap cluster can it be used to eliminate some of this? it can apply the mgmt cluster config, but not sure how to create yaml equivalents of clusterctl commands (clusterctl vs yaml - good idea or not?)
• deploy upstream chart via flux. e.g prometheus
• Cluster upgrade in blue/green fashion
• Try Cilium CNI
• Multi cluster mesh
• Multi cluster deployments with kubefed

Bugs and Improvements

• improve config management with clusterctl.yaml
• AWS cleanup script: if a mgmt cluster is removed without deleting a workload cluster need to clean up AWS resources manually. Also when tearing down a cluster via CAPI, the deletion is stuck for really long time (over 30min) just on VPC deletion (this is the last step). If I delete VPC from console while the CAPI deletion is still in progress then the CAPI deletion completes immediately. Maybe deleting raw AWS resources with script will be quicker.
• cleanup script: suspend flux if running, delete cluster definition from mgmt cluster, etc. Also clean up kubeconfig file from entries for deleted clusters
• is there a better way to wait for deployments ready after clusterctl init. Operator is mentioned in https://github.com/kubernetes-sigs/cluster-api PR 3825 from 2020. What operator?
• ClusterResourceSet is deprecated? What are the alternatives?
• Lock down access to cluster to specific IPs: ✨ Support overriding security groups in AWSCluster spec kubernetes-sigs/cluster-api-provider-aws#1933
• Scripted way to give access to other users (most likely with client certs)

[olga-mir]

CAPI operator: https://github.com/kubernetes-sigs/cluster-api-operator/blob/main/docs/capi-operator-proposal.md