4 posts tagged with "cluster"

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
metadata:
  name: brandName-database
spec:
  ports:
    - name: brandName-database-external
      protocol: TCP
      port: 3306
      targetPort: 3306

---
kind: Endpoints
apiVersion: v1
metadata:
  name: brandName-database
subsets:
  - addresses:
      - ip: 192.168.100.52
    ports:
      - port: 3306
        name: brandName-database-external

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

2. Get nodes and their labels

kubectl get nodes --show-labels

3. Deploy something to the cluster:

kubectl apply -f hetzner/domain.com-backend.yaml

4. Delete a deployment from the cluster:

kubectl delete -f https://k8s.io/examples/application/deployment.yaml

5. Get/watch logs from pod:

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

6. Delete pod:

kubectl delete pod/vt-vttablet-decontabodusseldorf-2620423388-0c5af156

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

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 https://raw.githubusercontent.com/vitessio/vitess/v14.0.0/examples/operator/operator.yaml

# 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.