clusters:
- cluster:
certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUN5RENDQWJDZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRFNU1EWXhOREUwTVRZd09Gb1hEVEk1TURZeE1URTBNVFl3TLS0tLS1CRUdJTiBDRV ... <many more characters>
server: https://134.34.224.84:6443
name: ccu-old
- cluster:
certificate-authority-data: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUM1ekNDQWMrZ0F3SUJBZ0lCQURBTkJna3Foa2lHOXcwQkFRc0ZBREFWTVJNd0VRWURWUVFERXdwcmRXSmwKY201bGRHVnpNQjRYRFRJeE1ERXhNakU1TURNMU0xb1hEVE14TURFeE1ERTVNRE0xTLS0tLS1CRUdJTiBDRV ... <many more characters>
server: https://ccu-k8s.inf.uni-konstanz.de:7443
name: ccu-new
<all the data below your username returned from the new loginapp goes here>
</syntaxhighlight>
Both the long CA data string and user credentials are returned from the respective loginapps of the clusters. If you have such a kubeconfig for multiple contexts, you can easily switch between the clusters:
<syntaxhighlight>
> kubectl config use-context ccu-old
> <... work with old cluster>
> kubectl config use-context ccu-new
> <... work with new cluster>
</syntaxhighlight>
Defining different contexts is also a good way to switch between namespaces (which should not be necessary for the average user).
=== Running the first test container on the new cluster ===