Working with vRack example - Managed Kubernetes and Public Cloud instances

Last updated July 27thth, 2021.

Objective

OVHcloud vRack is a private network solution that enables our customers to route traffic between OVHcloud dedicated servers as well as other OVHcloud services. At the same time, it allows you to add Public Cloud instances and Managed Kubernetes clusters to your private network to create an infrastructure of physical and virtual resources.

In this tutorial, we are going to activate the vRack on a Public Cloud project. Then we will create a Managed Kubernetes cluster and a Public Cloud instance (PCI). Eventually, both of them will be added inside the vRack.

Concretely, we are going to install an OVHcloud Managed Kubernetes cluster and a Public Cloud instance, both of them in the same private network. We are going to deploy a Wordpress on the Kubernetes cluster that will use the private network to connect to a MariaDB database installed on the Public Cloud instance.

In this tutorial we are going to give you an example of how to use the OVHcloud vRack to connect a Managed Kubernetes cluster with a Public Cloud instance inside the same private network.

The method described in this tutorial currently works if the Managed Kubernetes cluster and the external instance are in the same private network in the vRack. The process to connect them between different private networks will be described in a next tutorial.

Requirements

This tutorial presupposes that you already have a working OVHcloud Managed Kubernetes cluster, and some basic knowledge of how to operate it. If you want to know more on those topics, please look at the OVHcloud Managed Kubernetes Service Quickstart.

You also need to have Helm installed on your workstation and your cluster. Please refer to the How to install Helm on OVHcloud Managed Kubernetes Service tutorial.

It also supposes that you already have followed the Using vRack guide to activate the vRack on your Public Cloud project and put your OVHcloud Managed Kubernetes cluster inside the vRack.

Instructions

Setting up the vRack

First of all, we will need to set up vRack Private Network for our Public Cloud. To do it, we follow the Configuring vRack for Public Cloud guide. Once you have created a vRack and added it into a Private Network, you can continue.

Setting-up the vRack

As explained in the Known limits guide, the following subnets are not compliant with the vRack feature and can generate some incoherent behaviours with our used overlay networks:

10.2.0.0/16 # Subnet used by pods
10.3.0.0/16 # Subnet used by services
172.17.0.0/16 # Subnet used by the Docker daemon

Setting up the Managed Kubernetes

Then we create a Kubernetes cluster, as explained in the Create a cluster guide. Integrating a cluster into a vRack Private Network must be done at the third step on cluster creation, when we can choose an existing private network for the cluster:

Choose a private network for this cluster

Our new cluster will be created inside the vRack Private Network we have chosen.

In the Managed Kubernetes Service Dashboard, we can see the cluster, with the chosen private network in the Attached network column:

Private network information in Attached network column

Setting up the PCI

Now we can create a new Public Cloud instance inside the vRack, by following the Integrating an instance into vRack guide.

We are going to create an Ubuntu instance:

Setting-up PCI - Ubuntu instance

In the fourth step of creation, we attach it to the private network we created before:

Setting-up PCI - Attaching to a private network

After instance creation, we can see the connection details in the OVHcloud Control Panel. If we log in to the instance using SSH, we can see that it has two network interfaces, one attached to the public IP address we use to log in, the other attached to the private network:

horacio@my-laptop:~$ ssh ubuntu@51.68.xxx.xxx
Enter passphrase for key '/home/horacio/.ssh/id_rsa':
Welcome to Ubuntu 21.04 (GNU/Linux 5.11.0-18-generic x86_64)

  System information as of Fri Jun 18 04:37:54 UTC 2021

  System load:  0.0               Processes:             111
  Usage of /:   3.9% of 48.29GB   Users logged in:       0
  Memory usage: 2%                IPv4 address for ens3: 51.68.xxx.xxx
  Swap usage:   0%                IPv4 address for ens4: 10.0.128.251

ubuntu@example-vrack-k8s-pci:~$

Please take note of the private network IP address (in this case 10.0.128.251), as we will need to use it to configure WordPress.

Setting up MariaDB on the PCI

Installing MariaDB

The easiest way to install MariaDB in the PCI is to use the apt package manager:

sudo apt -y install mariadb-server

That will install MariaDB and all its dependencies:

ubuntu@example-vrack-k8s-pci:~$ sudo apt -y install mariadb-server
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following additional packages will be installed:
  [...]
Suggested packages:
  [...]
The following NEW packages will be installed:
  [...]
0 upgraded, 31 newly installed, 0 to remove and 0 not upgraded.
Need to get 15.3 MB of archives.
After this operation, 102 MB of additional disk space will be used.
Get:1 http://nova.clouds.archive.ubuntu.com/ubuntu hirsute/main amd64 mysql-common all 5.8+1.0.5ubuntu2 [7496 B]
  [...]
Get:19 http://nova.clouds.archive.ubuntu.com/ubuntu hirsute/main amd64 libcgi-fast-perl all 1:2.15-1 [10.5 kB]
Setting up libfcgi-bin (2.4.2-2) ...
  [...]
Setting up mariadb-server (1:10.5.10-0ubuntu0.21.04.1) ...
Setting up libcgi-fast-perl (1:2.15-1) ...
Processing triggers for man-db (2.9.4-2) ...
Processing triggers for libc-bin (2.33-0ubuntu5) ...
Scanning processes...
Scanning linux images...

Running kernel seems to be up-to-date.

No services need to be restarted.

No containers need to be restarted.

No user sessions are running outdated binaries.

Creating a user and a database

Now we can connect to the database using the mysql client:

sudo mysql

By default, the root account has no password when connected from the localhost, so we directly arrive to the MariaDB CLI.

Let's create a wordpress_db database and a wordpress_user user:

1. Create the database:

create database wordpress_db;

2. Create the user (with remote access) and grant privileges to this user on the new database:

grant all privileges on wordpress_db.* TO 'wordpress_user'@'%' identified by 'a_strong_password';

3. Apply the changes to be sure that the modifications on the MariaDB grant tables take effect immediately:

flush privileges;

The MariaDB instance is now ready.

ubuntu@example-vrack-k8s-pci:~$ sudo  mysql
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 37
Server version: 10.5.10-MariaDB-0ubuntu0.21.04.1 Ubuntu 21.04

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> create database wordpress_db;
Query OK, 1 row affected (0.000 sec)

MariaDB [(none)]> grant all privileges on wordpress_db.* TO 'wordpress_user'@'%' identified by 'a_strong_password';
Query OK, 0 rows affected (0.041 sec)

MariaDB [(none)]> flush privileges;
Query OK, 0 rows affected (0.001 sec)

MariaDB [(none)]> exit
Bye
ubuntu@example-vrack-k8s-pci:~$

Making MariaDB listen on the private network interface

By default, MariaDB only listens on localhost. In order to accept requests coming from the private network, we need to make it also listen on that network interface.

The easiest way to do it is by adding a bind_address line at the end of the global /etc/my.cnf configuration file:

bind-address = <MARIADB_ADDRESS>

Where <MARIADB_ADDRESS> is the private network IP address of the MariaDB instance (in this case 10.0.128.251).

Then restart MariaDB:

sudo service mariadb restart

And try to connect to MariaDB using that interface:

mysql -h<MARIADB_ADDRESS> -u wordpress_user -pa_strong_password

In this case:

~$ mysql -h10.0.128.251 -u wordpress_user -pa_strong_password
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 33
Server version: 10.5.10-MariaDB-0ubuntu0.21.04.1 Ubuntu 21.04

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| wordpress_db       |
+--------------------+
2 rows in set (0.02 sec)

MariaDB [(none)]> 

Accessing the MariaDB instance from the Managed Kubernetes cluster

To verify that the vRack is working as intended, let's test if we can access the MariaDB instance from the Managed Kubernetes cluster via the vRack.

We are deploying a MySQL client in the Kubernetes cluster, that will connect to the MariaDB instance using the vRack. Don't forget to replace <MARIADB_ADDRESS> with the private network IP address of the MariaDB instance (in this case 10.0.128.251).

kubectl run -it --rm --image=mysql:5.6 --restart=Never mysql-client -- mysql -h <MARIADB_ADDRESS> -uwordpress_user  -pa_strong_password
~$ kubectl run -it --rm --image=mysql:5.6 --restart=Never mysql-client -- mysql -h 10.0.128.251 -uwordpress_user  -pa_strong_password
If you don't see a command prompt, try pressing enter.

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| wordpress_db       |
+--------------------+
2 rows in set (0.01 sec)

mysql> exit
Bye
pod "mysql-client" deleted

Setting up WordPress

Now we have set up the database, we can deploy WordPress on the Kubernetes cluster. We are following a similar process as in our Installing WordPress tutorial, but adapting it to use an external database.

Using the WordPress Helm chart

For this tutorial we are using the WordPress Helm chart found on Bitnami repository. The chart is fully configurable, but we will only need to tweak the external database parameters:

mariadb.enabled
externalDatabase.host
externalDatabase.user
externalDatabase.password
externalDatabase.database
externalDatabase.port

As externalDatabase.host we will need to use the MariaDB instance's private network IP address, that be written down after creating the PCI.

helm install my-first-k8s-wordpress bitnami/wordpress --set mariadb.enabled=false,externalDatabase.host=<MARIADB_ADDRESS>,externalDatabase.user=wordpress_user,externalDatabase.password=a_strong_password,externalDatabase.database=wordpress_db,externalDatabase.port=3306 

Don't forget to replace <MARIADB_ADDRESS> with the private network IP address of the MariaDB instance (in this case 10.0.128.251).

~$ helm install my-first-k8s-wordpress bitnami/wordpress --set mariadb.enabled=false,externalDatabase.host=10.0.128.251,externalDatabase.user=wordpress_user,externalDatabase.password=a_strong_password,externalDatabase.database=wordpress_db,externalDatabase.port=3306
NAME: my-first-k8s-wordpress
LAST DEPLOYED: Tue Jul 27 11:11:48 2021
NAMESPACE: default
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
** Please be patient while the chart is being deployed **

Your WordPress site can be accessed through the following DNS name from within your cluster:

    my-first-k8s-wordpress.default.svc.cluster.local (port 80)

To access your WordPress site from outside the cluster follow the steps below:

1. Get the WordPress URL by running these commands:

  NOTE: It may take a few minutes for the LoadBalancer IP to be available.
        Watch the status with: 'kubectl get svc --namespace default -w my-first-k8s-wordpress'

   export SERVICE_IP=$(kubectl get svc --namespace default my-first-k8s-wordpress --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}")
   echo "WordPress URL: http://$SERVICE_IP/"
   echo "WordPress Admin URL: http://$SERVICE_IP/admin"

2. Open a browser and access WordPress using the obtained URL.

3. Login with the following credentials below to see your blog:

  echo Username: user
  echo Password: $(kubectl get secret --namespace default my-first-k8s-wordpress -o jsonpath="{.data.wordpress-password}" | base64 --decode)

Then we can follow the instructions to get the Admin URL:

~$ export SERVICE_IP=$(kubectl get svc --namespace default my-first-k8s-wordpress --template "{{ range (index .status.loadBalancer.ingress 0) }}{{.}}{{ end }}")

~$ echo "WordPress URL: http://$SERVICE_IP/"
WordPress URL: http://152.228.251.63/

~$ echo "WordPress Admin URL: http://$SERVICE_IP/admin"
WordPress Admin URL: http://152.228.251.63/admin  

And putting the URL in the browser will take us to the new blog, accessing the MariaDB database from the PCI instance via the vRack.

Setting-up Wordpress

Go further

Join our community of users on https://community.ovh.com/en/.


Did you find this guide useful?

Please feel free to give any suggestions in order to improve this documentation.

Whether your feedback is about images, content, or structure, please share it, so that we can improve it together.

Your support requests will not be processed via this form. To do this, please use the "Create a ticket" form.

Thank you. Your feedback has been received.


These guides might also interest you...

OVHcloud Community

Access your community space. Ask questions, search for information, post content, and interact with other OVHcloud Community members.

Discuss with the OVHcloud community

In accordance with the 2006/112/CE Directive, modified on 01/01/2015, prices incl. VAT may vary according to the customer's country of residence
(by default, the prices displayed are inclusive of the UK VAT in force).