Skip to main content

4 posts tagged with "cluster"

View All Tags

· One min read
Hreniuc Cristian-Alexandru

Check this

This is an example of how to connect an internal pod to an external db that is not inside the cluster. In the pod configuration you will need to connect to the brandName-database service from below.

apiVersion: v1
kind: Service
name: brandName-database
- name: brandName-database-external
protocol: TCP
port: 3306
targetPort: 3306

kind: Endpoints
apiVersion: v1
name: brandName-database
- addresses:
- ip:
- port: 3306
name: brandName-database-external

· One min read
Hreniuc Cristian-Alexandru

Make sure you have exported the KUBECONFIG env: export KUBECONFIG=/path/rke2_inventory/hetzner/credentials/rke2.yaml

  1. Get all pods and the nodes they are on
kubectl get pods -o wide
  1. Get nodes and their labels
kubectl get nodes --show-labels
  1. Deploy something to the cluster:
kubectl apply -f hetzner/
  1. Delete a deployment from the cluster:
kubectl delete -f
  1. Get/watch logs from pod:
kubectl logs -f pod/vt-vttablet-decontabodusseldorf-2620423388-0c5af156
  1. Delete pod:
kubectl delete pod/vt-vttablet-decontabodusseldorf-2620423388-0c5af156

· 6 min read
Hreniuc Cristian-Alexandru

Check when a new version is released here.

Development env - contabo

Update the vitess dev cluster first and see if everything works, check the logs of the vitess pods and also check if the backend can connect to the db.

cd vitess/contabo/

kubectl apply -f vitess-cluster.yaml

# Watch the pods being created
kubectl get pod

# Check logs
# Make sure the version is printed correctly: Version: 14.0.0
I0630 16:12:57.015279 1 servenv.go:100] Version: 14.0.0 (Git revision 9665c1850cf3e155667178104891f0fc41b71a9d branch 'heads/v14.0.0') built on Tue Jun 28 17:34:59 UTC 2022 by vitess@buildkitsandbox using go1.18.3 linux/amd64

# Vtgate - the last part of the name will be different
kubectl logs -f pod/vt-decontabodusseldorf-vtgate-f81fd0bc-5b7bfffb96-jxcjj

# vttablet
kubectl logs -f pod/vt-vttablet-decontabodusseldorf-2620423388-0c5af156

# vtctld
kubectl logs pod/vt-decontabodusseldorf-vtctld-55130465-65cd85fcc-n9ljn

Connect to the app and check the logs for the backend:

kubectl logs -f domain-com-backend-64d86787c5-g4vkv

· One min read
Hreniuc Cristian-Alexandru

Check when a new version is released here and check if it has been updated here, usually they only change the version of the operator image in that file.

Usually we should keep them in sync, the vitess-operator image and the vitess image.

When upgrading make sure you specify here the latest version used, so it will be easier to see what version we are using:

kubectl apply -f

# Vitess operator 2.7.1

kubectl get pod
# Logs

kubectl logs -f vitess-operator-647f7cc94f-zgf9q

Sometimes you might need to restart the backends, because this might trigger a restart for the vitess, and the backend sometimes doesn't refresh the connection ot the db. Check the logs of the backend.