The K3s installation script will automatically take the HTTP_PROXY, HTTPS_PROXY and NO_PROXY, as well as the CONTAINERD_HTTP_PROXY, CONTAINERD_HTTPS_PROXY and CONTAINERD_NO_PROXY variables from the current shell, if they are present, and write them to the environment file of your systemd service, usually:

These proxy settings will then be used in K3s and passed down to the embedded containerd and kubelet. If you are running K3s in an environment, which only has external connectivity through an HTTP proxy, you can configure your proxy settings on the K3s systemd service. It is possible to enable a second static token that can only be used to join agents, or to create temporary kubeadm style join tokens that expire automatically.įor more information, see the k3s token command documentation. This token cannot be changed once the cluster has been created. Token Management īy default, K3s uses a single static token for both servers and agents. Any certificates that are expired, or within 90 days of expiring, are automatically renewed every time K3s starts.įor information on manually rotating client and server certificates, see the k3s certificate rotate command documentation. K3s client and server certificates are valid for 365 days from their date of issuance. These CA certificates are valid for 10 years, and are not automatically renewed.įor information on using custom CA certificates, or renewing the self-signed CA certificates, see the k3s certificate rotate-ca command documentation. K3s generates self-signed Certificate Authority (CA) Certificates during startup of the first server node. Certificate Management Certificate Authority Certificates I had originally done this while still running DSM6.x, and it's still running perfectly after upgrading to DSM7.This section contains advanced information describing the different ways you can run and manage K3s, as well as steps necessary to prepare the host OS for K3s use. So far this change seems to persist perfectly through reboots and even a system upgrade. You should now be able to run docker and docker-compose commands without using sudo. In some cases you might have to restart your Synology NAS before it sticks. That's it! For this to take effect you should log out and then back in again. Lastly, let's modify who owns the docker.sock file, so that it now belongs to the docker user group we just created: ❯ sudo chown root:docker /var/run/docker.sock Assuming you are currently logged in with the user you wish to add, run the following: ❯ sudo synogroup -member docker $USER Note: If you want to add another user or if you happen to run all these commands within a sudo -s session, replace $USER with the name of the user account you wish to add. Now we can add our user to this newly created group. Note: For the following steps it is assumed that you are logged in to your Synology NAS using ssh with an account that has sudo permissions.įirst, let's create a new user group called docker: ❯ sudo synogroup -add docker These are, for whatever reason, replaced with Synology's proprietary tools. If you've already attempted to add a user to another user group, you might have noticed that the usual tools like usermod and groupadd don't actually exist on your Synology NAS. There are a few Synology-specific caveats though, so let's walk though the steps needed. Fortunately, as the underlying operating system is Linux after all, it's fairly easy to rectify this. For production setups it might be beneficial to maintain that level of security, but for a local/home setup it might not be all that useful, and can even be quite bothersome.īy default Synology's Docker package does not actually create this user group. If you've installed and used docker before, you're probably familiar with adding your computer's user account to the docker user group to allow you to control docker (and docker-compose) without needing to use sudo.

Sudo service docker start