Skip to main content
Version: 0.4.x

Edge node deployment

Deploy interLink on an edge node, outside the local K8S cluster.

Docusaurus themed imageDocusaurus themed image

Deploy Remote components​

In general, starting from the deployment of the remote components is adviced. Since the kubernetes virtual node won't reach the Ready status until all the stack is successfully deployed.

For this deployment mode the remote host has to allow the kubernetes cluster to connect to the Oauth2 proxy service port (30443 if you use the automatic script for installation)

You first need to initialize an OIDC client with you Identity Provider (IdP).

Since any OIDC provider working with OAuth2 Proxy tool will do the work, we are going to put the configuration for a generic OIDC identity provider in this cookbook. Nevertheless you can find more detailed on dedicated pages with instructions ready for GitHub, EGI checkin, INFN IAM.

Then download the latest release of the interLink installer:

mkdir -p $HOME/.interlink
export VERSION=$(curl -s https://api.github.com/repos/interlink-hq/interlink/releases/latest  | jq -r .name)
wget -O $HOME/interlink-installer https://github.com/interlink-hq/interLink/releases/download/$VERSION/interlink-installer_Linux_x86_64
chmod +x $HOME/.interlink/interlink-installer

Create a template configuration with the init option:

mkdir -p $HOME/.interlink/logs
mkdir -p $HOME/.interlink/bin
mkdir -p $HOME/.interlink/config
$HOME/.interlink/interlink-installer --init --config $HOME/.interlink/installer.yaml

The configuration file should be filled as followed. This is the case where the my-node will contact an edge service that will be listening on PUBLIC_IP and API_PORT authenticating requests from an OIDC provider https://my_oidc_idp.com:

$HOME/.interlink/installer.yaml
interlink_ip: PUBLIC_IP
interlink_port: API_PORT
interlink_version: X.X.X
kubelet_node_name: my-node
kubernetes_namespace: interlink
node_limits:
    cpu: "1000"
    # MEMORY in GB
    memory: 25600
    pods: "100"
oauth:
  provider: oidc
  issuer: https://my_oidc_idp.com/
  scopes:
    - "openid"
    - "email"
    - "offline_access"
    - "profile"
  audience: interlink
  grant_type: authorization_code
  group_claim: groups
  group: "my_vk_allowed_group"
  token_url: "https://my_oidc_idp.com/token"
  device_code_url: "https://my_oidc_idp/auth/device"
  client_id: "oidc-client-xx"
  client_secret: "xxxxxx"
insecure_http: true
note

Please fill interlink_version with the desired version.
In alternative get the latest with:

curl -s https://api.github.com/repos/interlink-hq/interlink/releases/latest  | jq -r .name

Now you are ready to start the OIDC authentication flow to generate all your manifests and configuration files for the interLink components. To do so, just execute the installer:

$HOME/.interlink/interlink-installer --config $HOME/.interlink/installer.yaml --output-dir $HOME/.interlink/manifests/

Install Oauth2-Proxy and interLink API server services and configurations with:

chmod +x $HOME/.interlink/manifests/interlink-remote.sh
$HOME/.interlink/manifests/interlink-remote.sh install

Then start the services with:

$HOME/.interlink/manifests/interlink-remote.sh start

With stop command you can stop the service. By default logs are store in ~/.interlink/logs, checkout there for any error before moving to the next step.

note

N.B. you can look the oauth2_proxy configuration parameters looking directly into the interlink-remote.sh script.

warning

N.B. logs (expecially if in verbose mode) can become pretty huge, consider to implement your favorite rotation routine for all the logs in ~/.interlink/logs/.

Plugin service​

Select here the featured plugin you want to try:

Offload your pods to a remote machine with Docker engine available.

  • Create a configuration file:

    $HOME/.interlink/config/plugin-config.yaml
    ## Multi user host
    Socket: "unix:///home/myusername/.interlink/.plugin.sock"
    InterlinkPort: "0"
    SidecarPort: "0"

    CommandPrefix: ""
    DataRootFolder: "/home/myusername/.interlink/jobs/"
    BashPath: /bin/bash
    VerboseLogging: false
    ErrorsOnlyLogging: false
    • N.B. Depending on wheter you edge is single user or not, you should know by previous steps which section to uncomment here.
    • More on configuration options at official repo

  • Download the latest release binary in $HOME/.interlink/bin/plugin for either GPU host or CPU host (tags ending with no-GPU)

  • Start the plugins passing the configuration that you have just created:

    export INTERLINKCONFIGPATH=$HOME/.interlink/config/plugin-config.yaml
    $HOME/.interlink/bin/plugin &> $HOME/.interlink/logs/plugin.log &
    echo $! > $HOME/.interlink/plugin.pid

  • Check the logs in $HOME/.interlink/logs/plugin.log.

  • To kill and restart the process is enough:

    # kill
    kill $(cat $HOME/.interlink/plugin.pid)

    # restart
    export INTERLINKCONFIGPATH=$HOME/.interlink/config/plugin-config.yaml
    $HOME/.interlink/bin/plugin &> $HOME/.interlink/logs/plugin.log &
    echo $! > $HOME/.interlink/plugin.pid

Almost there! Now it's time to add this virtual node into the Kubernetes cluster!

tip

Yes, if you will, you can also manage all interLink processes through systemd. Reach out to receive guidance on how we do it in production. You can find an example in the interlink repo ./systemd folder.

3rd-party plugins​

There are more 3rd-party plugins developed that you can get inspired by or even use out of the box. You can find some ref in the quick start section

interLink comes with a call that can be used to monitor the overall status of both interlink server and plugins, at once.

curl -v --unix-socket ${HOME}/.interlink/.interlink.sock  http://unix/pinglink

This call will return the status of the system and its readiness to submit jobs.

Deploy Kubernetes components​

The deployment of the Kubernetes components are managed by the official HELM chart. Depending on the scenario you selected, there might be additional operations to be done.

You can now install the helm chart with the preconfigured (by the installer script) helm values in ./interlink/manifests/values.yaml

  export INTERLINK_CHART_VERSION="X.X.X"
  helm upgrade --install \
  --create-namespace \
  -n interlink \
  my-node \
  oci://ghcr.io/interlink-hq/interlink-helm-chart/interlink \
  --version $INTERLINK_CHART_VERSION \
  --values ./.interlink/manifests/values.yaml
warning

Remember to pick the version of the chart and put it into the INTERLINK_CHART_VERSION env var above.

Whenever you see the node ready, you are good to go!

note

You can find a demo pod to test your setup here.

To start debugging in case of problems we suggest starting from the pod containers logs!