Learn Vitess - Basic Installation & Deployment

#Introduction

Enough theory from episode 2. Now we get our hands dirty: installing Vitess on Kubernetes and actually making it serve queries. Episode 3 is a big milestone because from here on you'll have a real Vitess cluster to explore — and every later episode will run on top of this foundation.

Episode 3 roadmap: cluster and storage preparation, installation via the official Helm chart, configuration of the first keyspace and shard, then verification of components and MySQL connectivity. Use the kind or k3d cluster you created in episode 0.

#Cluster Preparation

Before installing Vitess, make sure the cluster and helm are ready:

kubectl cluster-info
kubectl get nodes
helm version

kubectl get nodes must show nodes in Ready status. For a local lab, kind is sufficient. For a more production-like exercise, you can add nodes so there's a separate place for replicas and backups.

Vitess needs storage for each tablet's MySQL data. In kind, you need to make sure a storage class is available. The Vitess Helm chart uses PersistentVolumeClaim per tablet, so use the default storage class (in kind, standard already exists). Verify:

kubectl get storageclass

#Install with the Vitess Helm Chart

Vitess provides an official Helm chart in the vitess repo. Add the repo and update:

helm repo add vitess https://vitess.io/charts
helm repo update

Then install the chart with namespace vitess, and wait until the Pods are ready:

helm install vitess vitess/vitess \
  --namespace vitess \
  --create-namespace

kubectl get pods -n vitess -w

Helm will create many resources: vtctld, vtgate, and for each single-shard keyspace typically vtctld plus vtgate and etcd. Wait a few moments until all Pods are in Running status. If any is in CrashLoopBackOff, inspect with kubectl logs and kubectl describe pod — the most common causes are failed image pulls or unavailable storage.

#Configuring the First Keyspace and Shard

The default chart already provides the commerce keyspace with one shard 0. Verify through vtctlclient. Since vtctlclient isn't installed on your machine, use an alias via kubectl exec:

alias vtctlclient="kubectl exec -i -n vitess deploy/vtctld -- vtctlclient -server localhost:15999"
vtctlclient ListAllKeyspaces

vtctlclient ListAllKeyspaces should display commerce. To see all tablets:

vtctlclient ListAllTablets

The output shows the primary and replica tablets for shard 0 of the commerce keyspace, complete with their addresses. This is proof that VTGate, VTTablet, and Topology Service communicate properly.

If you want to adjust the number of shards during install (for example, a keyspace with 2 shards for resharding practice), use custom values:

topology:
  keyspaces:
    - name: commerce
      shards:
        - name: "-80"
        - name: "80-"

Then reinstall with helm install vitess vitess/vitess -f values-custom.yaml.

#Verifying Service Components

All components should be running now. Check the summary:

kubectl get deployments -n vitess
kubectl get statefulsets -n vitess
kubectl get svc -n vitess

There should be a vtctld and vtgate deployment, plus services exposing both. To access VTGate from your machine (port 15306 for the MySQL protocol), create a port-forward:

kubectl port-forward -n vitess svc/vtgate 15306:3306 &

#First MySQL Connection

Now the most fun part: connecting to Vitess just like regular MySQL. Open another terminal and run:

mysql -h 127.0.0.1 -P 15306 -u root

At the MySQL prompt, you can explore the keyspace and create a table:

USE commerce
SHOW TABLES
CREATE TABLE users (
  user_id bigint,
  name varchar(255),
  primary key (user_id)
)

The CREATE TABLE users command creates a table in the commerce keyspace. Since there's no VSchema yet, this table is considered unsharded — all data goes into shard 0. In episode 4 we'll see how VSchema changes how data is stored and routed.

#Closing

In this episode 3 you successfully deployed Vitess on Kubernetes with Helm, verified the commerce keyspace and its tablet shards via vtctlclient, then connected to VTGate with the mysql client and created your first table. This is the practical foundation for all the episodes that follow.

Key takeaways:

• Installing Vitess is as simple as helm install vitess vitess/vitess.
• vtctlclient ListAllKeyspaces and ListAllTablets are the main verification tools.
• The default chart creates a single-shard commerce keyspace for practice.
• VTGate is exposed on port 15306 and can be accessed with a regular mysql client.
• Tables created before a VSchema exists are automatically treated as unsharded.

In the next episode, episode 4, we manage keyspaces and shards: creating a keyspace from scratch, choosing the sharding key and vindex, adding shards, and understanding partitioning best practices. See you there!