kind is a tool for running local Kubernetes clusters using Docker container nodes. This guide uses kind to demonstrate deployment and operation of Submariner in three Kubernetes clusters running locally on your computer.
Submariner provides automation to deploy clusters using kind and connect them using Submariner.
To create kind clusters and deploy Submariner, run:
git clone https://github.com/submariner-io/submariner
cd submariner
make deploy
By default, the automation configuration in the main submariner-io/submariner repository deploys three clusters, with cluster1 configured as the Broker. See the cluster-settings file for details.
If you wish to try out Submariner deployment manually, an easy option is to create kind clusters using our scripts and deploy Submariner
with subctl.
To create kind clusters, run:
git clone https://github.com/submariner-io/submariner
cd submariner
make clusters
This creates three Kubernetes clusters: cluster1, cluster2 and cluster3. To see the list of kind clusters, use the following command:
$ kind get clusters
cluster1
cluster2
cluster3
To list the local Kubernetes contexts, use the following command:
$ kubectl config get-contexts
CURRENT NAME CLUSTER AUTHINFO NAMESPACE
cluster1 cluster1 cluster1
cluster2 cluster2 cluster2
* cluster3 cluster3 cluster3
Since multiple clusters are running, you need to choose which cluster kubectl talks to. You can set a default cluster for kubectl by
setting the current context in the Kubernetes kubeconfig file. Additionally, you can run the following command to set the current context
for kubectl:
kubectl config use-context <cluster name>
For more information on interacting with kind, please refer to the kind documentation.
subctl
curl -Ls https://get.submariner.io | bash
export PATH=$PATH:~/.local/bin
echo export PATH=\$PATH:~/.local/bin >> ~/.profile
subctl deploy-broker --kubeconfig output/kubeconfigs/kind-config-cluster1 --service-discovery
subctl join --kubeconfig output/kubeconfigs/kind-config-cluster2 broker-info.subm --clusterid cluster2 --disable-nat
subctl join --kubeconfig output/kubeconfigs/kind-config-cluster3 broker-info.subm --clusterid cluster3 --disable-nat
You now have a Submariner environment that you can experiment with.
subctlThis will perform automated verifications between the clusters.
subctl verify output/kubeconfigs/kind-config-cluster2 output/kubeconfigs/kind-config-cluster3 --only service-discovery,connectivity --verbose
To manually verify the deployment, follow the steps below using either a headless or ClusterIP nginx service deployed in cluster3.
kubectl --kubeconfig output/kubeconfigs/kind-config-cluster3 create deployment nginx --image=nginx
kubectl --kubeconfig output/kubeconfigs/kind-config-cluster3 expose deployment nginx --port=80
subctl export service --kubeconfig output/kubeconfigs/kind-config-cluster3 --namespace default nginx
Headless Services can only be exported on non-Globalnet deployments.
kubectl --kubeconfig output/kubeconfigs/kind-config-cluster3 create deployment nginx --image=nginx
kubectl --kubeconfig output/kubeconfigs/kind-config-cluster3 expose deployment nginx --port=80 --cluster-ip=None
subctl export service --kubeconfig output/kubeconfigs/kind-config-cluster3 --namespace default nginx
Run nettest from cluster2 to access the nginx service:
kubectl --kubeconfig output/kubeconfigs/kind-config-cluster2 -n default run --generator=run-pod/v1 \
tmp-shell --rm -i --tty --image quay.io/submariner/nettest -- /bin/bash
curl nginx.default.svc.clusterset.local
When you are done experimenting and you want to delete the clusters deployed in any of the previous steps, use the following command:
make cleanup