IKO - Lessons Learned (Part 3 - Services 101 and The Sidecars)

The IKO allows for sidecars. The idea behind them is to have direct access to a specific instance of IRIS. If we have mirrored data nodes, the web gateway will (correctly) only give us access to the primary node. But perhaps we need access to a specific instance. The sidecar is the solution.

Building on the example from the previous article, we introduce the sidecar by using a mirrored data node and of course arbiter.

apiVersion: intersystems.com/v1alpha1
kind: IrisCluster
metadata:
  name: simple
spec:
  licenseKeySecret:
    #; to activate ISC license key
    name: iris-key-secret
  configSource:
    #; contains CSP-merge.ini, which is merged into IKO's
    #; auto-generated configuration.
    name: iris-cpf
  imagePullSecrets:
    - name: intersystems-pull-secret

  topology:
    data:
      image: containers.intersystems.com/intersystems/irishealth:2023.3
      compatibilityVersion: "2023.3"
      mirrored: true
      webgateway:
        image: containers.intersystems.com/intersystems/webgateway:2023.3
        type: apache
        replicas: 1
        applicationPaths:
          - /csp/sys
          - /csp/healthshare
          - /api/atelier
          - /csp/broker
          - /isc
          - /oauth2
          - /ui
        loginSecret:
           name: iris-webgateway-secret
           
    arbiter:
     image: containers.intersystems.com/intersystems/arbiter:2023.3
    webgateway:
      replicas: 1
      image: containers.intersystems.com/intersystems/webgateway:2023.3
      applicationPaths:
        #; All of the IRIS instance's system default applications.
        #; For Management Portal only, just use '/csp/sys'.
        #; To support other applications, please add them to this list.
        - /csp/sys
        - /csp/broker
        - /api
        - /isc
        - /oauth2
        - /ui
        - /csp/healthshare
      alternativeServers: LoadBalancing
      loginSecret:
        name: iris-webgateway-secret

  serviceTemplate:
    # ; to enable external IP addresses
    spec:
      type: LoadBalancer

Notice how the sidecar is nearly identical to the 'maincar' webgateway. It just is placed within the data node. That's because it's a second container that sits in the pod alongside the IRIS image. This all sounds great. But how do we actually access it? The IKO nicely creates services for us, but for the sidecar that responsibility will fall on us.

So how do we expose this webgateway? With a service like this:

apiVersion: v1
kind: Service
metadata:
  name: sidecar-service
spec:
  ports:
  - name: http
    port: 81
    protocol: TCP
    targetPort: 80
  selector:
    intersystems.com/component: data
    intersystems.com/kind: IrisCluster
    intersystems.com/mirrorRole: backup
    intersystems.com/name: simple
    intersystems.com/role: iris
  type: LoadBalancer

Now our 'maincar' service always points at the primary and the sidecar at the backup. But we very well could have created a sidecar service to expose data-0-0 and one to expose data-0-1, regardless of which is the primary or backup. Services give the possibility of exposing any pod we want and targeting it by what you notice is the selector, which just identifies a pod (or multiple pods) by its labels.

We've barely scratched the surface on services and haven't even mentioned their more sophisticated partner, ingress. You can read up more about that here in the meantime.

In the next bite sized article we'll cover the storage class.