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.