Installing Nodes with Kubernetes

Installing Nodes with Kubernetes

This article describes how to install Crosser Nodes on a Kubernetes cluster.


Requirements

Before you start make sure you have the following dependencies ready and working:

  • Helm > 3

Installation

To simplify the setup Crosser provides a Helm chart, which can be installed from our repository with the following command:
helm upgrade --install --create-namespace -n <namespace> <releasename> oci://registry.crosser.cloud/charts/node --version 0.4.0 --values <path-to-your-values.yaml>

Before installing a node you need to update the values.yaml  file with credentials to the Crosser Docker registry and for your Crosser Node. This information can be found in Control Center on the Nodes page and the Register Nodes tab (Docker credentials are available in the Advancced options section).

Configuration

The values.yaml file is divided into a node specific configuration section, and a Kubernetes deployment specific section.

Examples of a typical config files:

# values.yaml (with nodeId and accessKey)
registry:
  host: docker.crosser.io
  username: username
  password: password
node:
  nodeID:  nodeid
  accessKey: accesskey
expose:
  type: ClusterIP

# values.yaml (with globalKey registration)

registry:
  host: docker.crosser.io
  username: username
  password: password
node:
  globalKey:
    enabled: true
    registrationKey: your-global-key

# values.yaml (with ingress with basic-auth)

registry:
  host: docker.crosser.io
  username: username
  password: password
node:
  nodeID:  nodeid
  accessKey: accesskey
expose:
  ingress:
    enabled: true
    host: crossernode.domain.tld
    auth:
      enabled: true
      username: "edgenode"
      password: "edgenode"
    tls:
      enabled: true

# values.yaml (with ingress and openshift edge termination)

registry:
  host: docker.crosser.io
  username: username
  password: password
node:
  nodeID:  nodeid
  accessKey: accesskey
expose:
  ingress:
    enabled: true
    host: crossernode.domain.tld
    tls:
      enabled: true
      openshiftEdgeTermination: true

Settings

The following table lists the configurable parameters of the chart and their default values.

ParameterDescriptionDefault
registryContainer registry credentials
Copy credentials from Crosser Cloud 		{"email":"name@domain.tld","host":"docker.crosser.io","password":"password","username":"username"}
node.nodeIDCopy nodeID from Crosser Cloud when you create an node""
node.accessKeyCopy accessKey from Crosser Cloud when you create an node""
node.globalKey.enabledSet to true if you want to use globalKey instead of nodeID and accessKeyFALSE
node.globalKey.registrationKeyThe global registration key you, or your administrator, generated in Crosser Cloud""
node.globalKey.registrationNameName you want to give the node (only alphanumerical characters and underscore are allowed in node names) If empty the name "Release.name" from the chart will be used""
node.baseURLURL the node will connect tocloud.crosser.io
node.logLevelLogLevel options are [Information, Debug]Information
node.proxyProxy settings{"enabled":false,"host":"http://username:password@proxy.domain.tld:8080","noproxy":""}
node.image.repositorydocker.crosser.io/crosser/edgenode
node.image.tagOverrides the image tag whose default is the chart appVersion.""
node.persistence.enabled# If true, use a Persistent Volume Claim, If false, use emptyDir #TRUE
node.persistence.resourcePolicySetting it to "keep" to avoid removing PVCs during a helm delete operation. Leaving it empty will delete PVCs after the chart deleted"keep"
node.persistence.persistentVolumeClaim.existingClaimUse the existing PVC which must be created manually before bound, and specify the "subPath" if the PVC is shared with other components""
node.persistence.persistentVolumeClaim.subPath
""
node.persistence.persistentVolumeClaim.storageClassSpecify the "storageClass" used to provision the volume. Or the default StorageClass will be used(the default). Set it to "-" to disable dynamic provisioning""
node.persistence.persistentVolumeClaim.accessMode
ReadWriteOnce
node.persistence.persistentVolumeClaim.size10Gi
node.serviceAccountNameSet the service account to be used, default if left empty""
node.resourcesDefine resources requests and limits for single Pods.
Ref: https://kubernetes.io/docs/user-guide/compute-resources/		{}
node.securityContextSecurityContext holds pod-level security attributes and common container settings. This defaults to non root user with uid 1000 and gid 1000. *v1.PodSecurityContext false
Ref: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/		{}
node.nodeSelectorDefine which Nodes the Pods are scheduled on.
Ref: https://kubernetes.io/docs/user-guide/node-selection/		{}
node.tolerationsIf specified, the pod's tolerations.
Ref: https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/		[]
node.affinityAssign custom affinity rules
Ref: https://kubernetes.io/docs/concepts/configuration/assign-pod-node/		{}
node.podAnnotationsAdditional deployment annotations{}
expose.typeSet the way how to expose the service. Set the type as "ClusterIP", "NodePort" or "LoadBalancer" and fill the information in the corresponding sectionClusterIP
expose.clusterIP.annotationsAnnotations on the ClusterIP service{}
expose.clusterIP.ports.httpPortThe service port the Node listens on when serving with HTTP/HTTPS9090
expose.clusterIP.ports.mqttPortThe service port the Node listens on when serving with MQTT1883
expose.clusterIP.ports.apiPortThe service port the Node API listens on9191
expose.nodePort.ports.httpServer.portThe service port the Node listens on when serving with HTTP/HTTPS9090
expose.nodePort.ports.httpServer.nodePortThe node port the Node listens on when serving with HTTP/HTTPS30002
expose.nodePort.ports.mqttServer.portThe service port the Node listens on when serving with MQTT1883
expose.nodePort.ports.mqttServer.nodePortThe node port the Node listens on when serving with MQTT30003
expose.nodePort.ports.apiServer.portThe service port the Node API listens on9191
expose.nodePort.ports.apiServer.nodePortThe node port the Node API listens on30004
expose.loadBalancer.IPSet the IP if the LoadBalancer supports assigning IP""
expose.loadBalancer.ports.httpPortThe service port the Node listens on when serving with HTTP/HTTPS9090
expose.loadBalancer.ports.mqttPortThe service port the Node listens on when serving with MQTT1883
expose.loadBalancer.ports.apiPortThe service port the Node API listens on9191
expose.loadBalancer.annotations{}
expose.loadBalancer.sourceRanges[]
expose.ingress.enabledIngress will only be installed when type is "ClusterIP" HTTP/HTTPS is only supported in this versionFALSE
expose.ingress.hostcrossernode.domain.tld
expose.ingress.ingressClassnginx
expose.ingress.annotations{}
expose.ingress.auth.enabled 
Enable to use Basic Authentication ! Will not work in Openshift ! 
FALSE
expose.ingress.auth.username 
Username to use for authentication 
"edgenode"
expose.ingress.auth.password 
Password to use for authentication 
"edgenode"
expose.ingress.tls.enabledFALSE
expose.ingress.tls.openshiftEdgeTermination 
Only set this to true if you will be installing in Openshift and want to have secured routes with edge TLS termination 
FALSE
expose.ingress.tls.certSourceThe source of the tls certificate. Set it as "auto", "secret" or "none" and fill the information in the corresponding section 1) auto: generate the tls certificate automatically 2) secret: read the tls certificate from the specified secret. The tls certificate can be generated manually or by cert manager 3) none: configure no tls certificate for the ingress. If the default tls certificate is configured in the ingress controller, choose this optionauto
expose.ingress.tls.auto.commonNameThe common name used to generate the certificate, it's necessary when the type isn't "ingress"""
expose.ingress.tls.secret.secretNameThe name of secret which contains keys named: "tls.crt" - the certificate "tls.key" - the private key""

    • Related Articles

    • Node Installation

      The first step when installing a local edge Node is to register the Node in Crosser Cloud to get the credentials. This is covered in the In Crosser Cloud section below. There are two options for installing a Crosser Node on a local server: using a ...

    • Labels

      Labels Creating and Using labels Labels are used to create groups of nodes. A label is just a text string that you attach to a node. On the Nodes page you can add a label to a Node by clicking on the plus sign (+) in the labels column next to the ...

    • Crosser Control Center On-Prem

      This article describes the high-level system architecture of Crosser Control Center and highlights the requirements as well as consequences of running Crosser Control Center on-prem. System architecture The Crosser Control Cloud consists of several ...

    • Flow Deployment and Versions

      Flow Deployment Once you have built and tested a new flow in the Flow Studio it’s time to deploy it on some nodes for production usage. There are two ways you can do this: Deploying flows from the Flows page On the flows page you can use ...

    • Deploy Your Flow

      Deploy Your Flow These steps does not apply to a Sandbox, you cannot deploy a flow to a Sandbox. In order to be able to deploy a flow to a Crosser node you first need to have registered your nodes. (Please see Node installation for more information) ...