Open garloff opened 10 months ago
I should mention that providing consistency here would make the make fullclean
option a lot better and safer.
(See #484, #492).
The CAPO has in its networking module following:
const (
networkPrefix string = "k8s-clusterapi"
trunkResource string = "trunks"
portResource string = "ports"
)
Then the router name is obtained by:
func getRouterName(clusterName string) string {
return fmt.Sprintf("%s-cluster-%s", networkPrefix, clusterName)
}
The network and subnet name is obtained by:
func getSubnetName(clusterName string) string {
return fmt.Sprintf("%s-cluster-%s", networkPrefix, clusterName)
}
func getNetworkName(clusterName string) string {
return fmt.Sprintf("%s-cluster-%s", networkPrefix, clusterName)
}
func GetDescription(clusterName string) string {
return fmt.Sprintf("Created by cluster-api-provider-openstack cluster %s", clusterName)
}
However, this description get used in multiple resources:
fpCreateOpts.FloatingNetworkID = openStackCluster.Status.ExternalNetwork.ID
fpCreateOpts.Description = names.GetDescription(clusterName)
Here it would be probably possible to add tags.
The CAPO has the following in the load balancer module:
const (
networkPrefix string = "k8s-clusterapi"
kubeapiLBSuffix string = "kubeapi"
)
And then the name is obtained by:
func getLoadBalancerName(clusterName string) string {
return fmt.Sprintf("%s-cluster-%s-%s", networkPrefix, clusterName, kubeapiLBSuffix)
}
const (
secGroupPrefix string = "k8s"
controlPlaneSuffix string = "controlplane"
workerSuffix string = "worker"
bastionSuffix string = "bastion"
remoteGroupIDSelf string = "self"
)
func getSecControlPlaneGroupName(clusterName string) string {
return fmt.Sprintf("%s-cluster-%s-secgroup-%s", secGroupPrefix, clusterName, controlPlaneSuffix)
}
func getSecWorkerGroupName(clusterName string) string {
return fmt.Sprintf("%s-cluster-%s-secgroup-%s", secGroupPrefix, clusterName, workerSuffix)
}
func getSecBastionGroupName(clusterName string) string {
return fmt.Sprintf("%s-cluster-%s-secgroup-%s", secGroupPrefix, clusterName, bastionSuffix)
}
In cloud provider for OpenStack in load balancer following setting is set:
const (
servicePrefix = "kube_service_"
...
func (lbaas *LbaasV2) GetLoadBalancerName(_ context.Context, clusterName string, service *corev1.Service) string {
name := fmt.Sprintf("%s%s_%s_%s", servicePrefix, clusterName, service.Namespace, service.Name)
return cpoutil.CutString255(name)
}
func getSecurityGroupName(service *corev1.Service) string {
securityGroupName := fmt.Sprintf("lb-sg-%s-%s-%s", service.UID, service.Namespace, service.Name)
//OpenStack requires that the name of a security group is shorter than 255 bytes.
if len(securityGroupName) > 255 {
securityGroupName = securityGroupName[:255]
}
return securityGroupName
}
floatIPOpts := floatingips.CreateOpts{
FloatingNetworkID: svcConf.lbPublicNetworkID,
PortID: portID,
Description: fmt.Sprintf("Floating IP for Kubernetes external service %s from cluster %s", serviceName, clusterName),
}
- I have not been able to find where PVCs get their names.
In the past, I created an issue yaook/k8s#465. It is not about PV names(the user specifies PVC names, and PV names look random(probably some request ID)) but their description and tags.
Each volume created by cinder CSI has description Created by OpenStack Cinder CSI driver.
Also, the tag cinder.csi.openstack.org/cluster=<cluster_name>
is added there. We already set this value here. So in the volume metadata we can see property like cinder.csi.openstack.org/cluster='testcluster'.
The same happens with volume snapshots.
Let's split this in multiple tasks
After the ClusterClass feature #600, control-plane resources also lack $PREFIX. In this issue, it was marked as OK, but now it should be:
Because of this change, we had to also modify our full cleanup script, from grep $PREFIX-$CLUSTER_NAME
to grep "$PREFIX-$CLUSTER_NAME\|$CLUSTER_NAME-control-plane"
which is IMO not good.
Also, in the PR https://github.com/SovereignCloudStack/k8s-cluster-api-provider/pull/661#issuecomment-1842931890, the naming of control-plane resources will be reduced even more.
The naming of ClusterClass resources can be seen in the CAPI issue https://github.com/kubernetes-sigs/cluster-api/issues/9135 - we can also see, that machine deployment resources have no problem so far because, in the naming scheme, there is also {topology-name}
which is in our case is "${PREFIX}-${CLUSTER_NAME}-md-0-no1".
The only way as far as I can see for now is to add a prefix to control-plane resources by changing the cluster name itself by adding of prefix there.
I'll close this because it's related to KaaS v1 which will be deprecated after R7. Feel free to reopen, if I'm wrong
I'll close this because it's related to KaaS v1 which will be deprecated after R7. Feel free to reopen, if I'm wrong
Just realized, I was wrong. We have the problem, that the name for the ingress-nginx loadbalancer is always the same and then it errors inside of openstack when there are more then one, related to this comment.
@michal-gubricky please find out how to configure clusterName
using Cluster API to avoid changing code upstream.
Seems like this value will be enough to set.
Seems like this value will be enough to set.
I will take a look at it and test it.
Seems like this value will be enough to set.
I will take a look at it and test it.
After investigation, setting this variable should do the job. The cluster name is set to kubernetes by default via an environment variable. This can be seen, for example, by describing a pod of OCCM.
Environment:
CLOUD_CONFIG: /etc/config/cloud.conf
CLUSTER_NAME: kubernetes
and can also be found in values.yaml
As a cluster administrator, I want to be able to identify all IaaS resources that belong to a cluster, so I know what to save and what I can possibly safely delete when cleaning up.
Looking at the various resources at the OpenStack level, we do not consistently prefix everything with (per mgmthost) prefix and clustername. Here's what we find:
MgmtServer:
Cluster
Ingress
Persistent Volumes
I may have overlooked some resource.
So, we should look at
I am not sure that all of this can easily be addressed without hacking OCCM/CSI. But then we maybe should do that ...