Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Machine api mvp #119

Merged
merged 3 commits into from
Sep 13, 2018
Merged

Machine api mvp #119

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
b00e40e
vendor: Add client from sigs.k8s.io/cluster-api
enxebre Sep 4, 2018
124ac35
*: Use machine-api-operator to deploy worker nodes
enxebre Sep 4, 2018
d92a22a
Documentation: Add info on allowing libvirt TCP connections
bison Sep 12, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
The table of contents is too big for display.
Diff view
Diff view
  •  
  •  
  •  
51 changes: 47 additions & 4 deletions Documentation/dev/libvirt-howto.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -40,7 +40,50 @@ polkit.addRule(function(action, subject) {
EOF
```

#### 1.6 Prepare the configuration file
#### 1.6 Configure libvirt to accept TCP connections

The Kubernetes [cluster-api](https://github.com/kubernetes-sigs/cluster-api)
components drive deployment of worker machines. The libvirt cluster-api
provider will run inside the local cluster, and will need to connect back to
the libvirt instance on the host machine to deploy workers.

In order for this to work, you'll need to enable TCP connections for libvirt.
To do this, first modify your `/etc/libvirt/libvirtd.conf` and set the
following:
```
listen_tls = 0
listen_tcp = 1
auth_tcp="none"
tcp_port = "16509"
```

Note that authentication is not currently supported, but should be soon.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are there blockers to supporting TLS at least? Or a way to restrict the listening to an interface that's only exposed to libvirt domains? Relying on the firewall as the only thing between external users and control of my libvirtd makes me jumpy. But I'm not very familiar with libvirt, so maybe I'm just misunderstanding :p.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm working on TLS authentication support in the actuator now. It's not there yet, but will be soon.


In addition to the config, you'll have to pass an additional command-line
argument to libvirtd. On Fedora, modify `/etc/sysconfig/libvirtd` and set:

```
LIBVIRTD_ARGS="--listen"
```

On Debian based distros, modify `/etc/default/libvirtd` and set:

```
libvirtd_opts="--listen"
```

Next, restart libvirt: `systemctl restart libvirtd`

Finally, if you have a firewall, you may have to allow connections from the IP
range used by your cluster nodes. If you're using the default subnet of
`192.168.124.0/24`, something along these lines should work:

```
iptables -I INPUT -p tcp -s 192.168.124.0/24 -d 192.168.124.1 --dport 16509 \
-j ACCEPT -m comment --comment "Allow insecure libvirt clients"
```

#### 1.7 Prepare the configuration file
1. `cp examples/tectonic.libvirt.yaml ./`
1. Edit the configuration file:
1. Set an email and password in the `admin` section
Expand All @@ -51,7 +94,7 @@ EOF
1. Look at the `podCIDR` and `serviceCIDR` fields in the `networking` section. Make sure they don't conflict with anything important.
1. Set the `pullSecret` to your JSON pull secret.

#### 1.7 Set up NetworkManager DNS overlay
#### 1.8 Set up NetworkManager DNS overlay
This step is optional, but useful for being able to resolve cluster-internal hostnames from your host.
1. Edit `/etc/NetworkManager/NetworkManager.conf` and set `dns=dnsmasq` in section `[main]`
2. Tell dnsmasq to use your cluster. The syntax is `server=/<baseDomain>/<firstIP>`. For this example:
Expand All @@ -60,14 +103,14 @@ echo server=/tt.testing/192.168.124.1 | sudo tee /etc/NetworkManager/dnsmasq.d/t
```
3. `systemctl restart NetworkManager`

#### 1.8 Install the terraform provider
#### 1.9 Install the terraform provider
1. Make sure you have the `virsh` binary installed: `sudo dnf install libvirt-client libvirt-devel`
2. Install the libvirt terraform provider:
```sh
GOBIN=~/.terraform.d/plugins go get -u github.com/dmacvicar/terraform-provider-libvirt
```

#### 1.9 Cache terrafrom plugins (optional, but makes subsequent runs a bit faster)
#### 1.10 Cache terrafrom plugins (optional, but makes subsequent runs a bit faster)
```sh
cat <<EOF > $HOME/.terraformrc
plugin_cache_dir = "$HOME/.terraform.d/plugin-cache"
Expand Down
5 changes: 4 additions & 1 deletion examples/tectonic.libvirt.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,10 @@ admin:
baseDomain:

libvirt:
uri: qemu:///system
# You must specify an IP address here that libvirtd is listening on,
# and that the cluster-api controller pod will be able to connect
# to. Often 192.168.122.1 is the default for the virbr0 interface.
uri: qemu+tcp://192.168.122.1/system
network:
name: tectonic
ifName: tt0
Expand Down
Loading