From the interface where an inet6 addr op `Scope:Global` is listed, these are the addresses in the example above:
* public ipv6 address: 2001:6a8:1d80:2021:230:48ff:fe78:f4d0
* local ipv4 address: **10.2.0.211**
The local ipv4 address of the Kubernetes master node is what `<KUBE_MASTER_IP>` refers to elsewhere in this documentation.
This `<KUBE_MASTER_IP>` is accessible from your machine without further work, if you're connected to the iGent network.
If not connected to the iGent network (and your network connection does not support ipv6), you need a public ipv4 address to talk to in the virtual wall.
The virtual wall has different solutions, of which we'll select one below.
* Configure the Kubernetes master node (a bare metal server) to have a public ipv4 address.
* We won't select this option, because it complicates the Kubernetes environment.
We certainly do not want Kubernetes traffic over the public ipv4 address.
Note that there are issues with Kubernetes to select a network interface.
* Add an extra virtual wall node inside the current experiment (a bare metal server or a XEN VM) with a public ipv4 address, and forward ports.
* We won't select this option, because it is overhead when connected to the iGent network.
* Make a small helper experiment (rspec based), containing one node (a bare metal server or a XEN VM, with a public ipv4 address, on the same virtual wall as the Kubernetes experiment), and forward ports.
This solution is based on the fact that all virtual wall nodes on the same wall can connect with each other.
* We'll select this option, because it leaves the original experiment unchanged. Follow the steps below.
Do the next steps after the Kubernetes experiment was started and is up and running.
In jFED, obtain the virtual wall node name of the Kubernetes master node, using the context menu `Show Node Info`.
Example node name: **n079-01.wall1.ilabt.iminds.be**.
We'll refer to this node name below as `<KUBE_MASTER_NODENAME>`.
In jFed, create a new rspec.
Drag a `XEN VM` on the diagram.
We select this type of resource, because it's the easiest way to obtain a public ipv4 address. We follow [this documentation](https://doc.ilabt.imec.be/ilabt/virtualwall/network.html#requesting-a-public-ipv4-address-for-a-xen-vm).
A `Physical Node` is an other valid choice, but then you'll need to follow [this documentation](https://doc.ilabt.imec.be/ilabt/virtualwall/network.html#requesting-and-configuring-public-ipv4-addresses-on-bare-metal-servers).
Right-mouse-click on the node and configure as follows:
* General
* Node name: forwarder
* Test bed: the same as where the Kubernetes experiment runs
* Routable Control IP
* Routable Control IP: yes
Optionally, save this rspec for future use.
Run this experiment.
Open a terminal to the `forwarder` node.
Find it's ipv4 address using `ifconfig`.
Example forwarder ipv4 address: **193.190.127.170**.
We'll refer to this address below as `<FORWARDER_IP>`.
Establish SSH port forwardings.
In the normal instructions, the following addresses are visited:
*`http://<KUBE_MASTER_IP>:<GRAFANA_PORT>`
*`http://<KUBE_MASTER_IP>:<INFLUXDB_PORT>/...`
So, in the terminal to the `forwarder` node, we'll forward as follows (in general):
Finally, we can now access Grafana and InfluxDB from our local machine, by replacing `<KUBE_MASTER_IP>` with `<FORWARDER_IP>` in the normal instructions!
