Kubernetes (commonly stylized as k8s) is an open-source container-orchestration system for automating application deployment, scaling, and management. It aims to provide a platform for automating deployment, scaling, and operations of application containers across clusters of hosts. It works with a range of container tools, including Docker.
Hi!
We are working on containerizing our IRIS product. We want to extract the message log that is shown in the terminal, but if possible, we want to format the output as JSON and include some extra fields from the instance to enhance our monitoring. Is this possible?
Any guide or example about it?
Thanks!
In case you're planning on deploying IRIS For Health, or any of our containerized products, via the IKO on OpenShift, I wanted to share some of the hurdles we had to overcome.
As with any IKO based installation, we first need to deploy the IKO itself. However we were getting this error:
Warning FailedCreate 75s (x16 over 3m59s) replicaset-controller Error creating: pods "intersystems-iris-operator-amd-f6757dcc-" is forbidden: unable to validate against any security context constraint:
proceeded by a list of all the security context constraints (SCCs) it could not validate against.
Hi!
We are deploying the iris image in a Kubernetes environment and the cluster state is "Hung" , looking the alerts endpoint we get 2 alerts:
[
{
"time":"2026-03-24T13:45:44.548Z",
"severity":"2",
"message":"System appears to have failed over from node a69a9f137593"
},
{
"time":"2026-03-24T13:46:30.274Z",
"severity":"2",
"message":"Error: <PROTECT>KillAlive+1^%SYS.CDIRECT in SERVERS"
}
]
Any idea / help where those are comming from and how to address them?
We are trying to run the HS solution inside of a container, but we are getting the following errors un start up
03/17/26-10:19:05:108 (1386) 1 [Generic.Event] Cannot lock /usr/irissys/mgr/hslib/ err(13): will try accessing readonly
03/17/26-10:19:08:174 (1386) 1 [Generic.Event] Cannot lock /usr/irissys/mgr/enslib/ err(13): will try accessing readonly
I understand that those databases should be mounted as read only don't needing the lock, any idea how to fix it? or where should I look to configure it correctly?
Thanks!
.png)
For those of us building InterSystems workloads on Kubernetes, we are definitely spoiled with the InterSystems Kubernetes Operator (IKO) doing the heavy lifting and mirroring on day one. Where us spoiled brats jump up and down is when we try to add additional databases/namespaces when we provision from HealthConnect containers on day two, while others get to utilize HealthShare Mirroring for this task, the prerequisite of mirroring HSSYS out of the gate has been somewhat elusive. Here is example on how you can this powerful feature up and running with the employment of IKO and IrisClusters.
Monitoring your IRIS deployment is crucial. With the deprecation of System Alert and Monitoring (SAM), a modern, scalable solution is necessary for real-time insights, early issue detection, and operational efficiency. This guide covers setting up Prometheus and Grafana in Kubernetes to monitor InterSystems IRIS effectively.
This guide assumes you already have an IRIS cluster deployed using the InterSystems Kubernetes Operator (IKO), which simplifies deployment, integration and mangement.
Introduction
In today's rapidly evolving threat landscape, organizations deploying mission-critical applications must implement robust security architectures that protect sensitive data while maintaining high availability and performance. This is especially crucial for enterprises utilizing advanced database management systems like InterSystems IRIS, which often powers applications handling highly sensitive healthcare, financial, or personal data.
.png)
A few days before Kubecon, the external-secrets-operator went GA with 1.0.0 and is set to ride shotgun for Kubernetes Secrets Management and put Vault in the backseat. You can glance at the "Providers" list for the solution and immediatley understand that you can leave the "which Secrets Manager" conversation to others while you do your job utilizing external secrets on your IrisCluster workloads, which by my count with the operator and a single IrisCluster is more than a fistful of secrets of different types, even under a single tenant. So let them sprawl, the secrets managers that is, not the secrets.
.png)
If you're running IRIS in a mirrored IrisCluster for HA in Kubernetes, the question of providing a Mirror VIP (Virtual IP) becomes relevant. Virtual IP offers a way for downstream systems to interact with IRIS using one IP address. Even when a failover happens, downstream systems can reconnect to the same IP address and continue working.
The lead in above was stolen (gaffled, jacked, pilfered) from techniques shared to the community for vips across public clouds with IRIS by @Eduard Lebedyuk ...
Articles: ☁ vip-aws | vip-gcp | vip-azure
This version strives to solve the same challenges for IRIS on Kubernetes when being deployed via MAAS, on prem, and possibly yet to be realized using cloud mechanics with Manged Kubernetes Services.
.png)
Hello cpf fans! This distraction I used the "seed" capability in IRIS to provision an entire IrisCluster mirror, 4 maps wide with compute starting from an IRIS.DAT in a galaxy far far away. This is pretty powerful if you have had a great deal of success with a solution running on a monolithic implementation and want it to scale to the outer rim with Kubernetes and the InterSystems Kubernetes Operator. Even though my midichlorian count is admittely low, I have seen some hardcore CACHE hackers shovel around DATS, compact and shrink and update their ZROUTINES, so this same approach could also be helpful shrinking and securing your containerized workload too. If you squint and feel all living things around you, you can see a glimpse of in place (logical) mirroring in the future as a function of the operator and a migration path to a fully operational mirrored Death Star as the workload matures.
.png)
Here is an option for your headspace if you are designing an multi-cluster architecture and the Operator is an FTE to the design. You can run the Operator from a central Kubernetes cluster (A), and point it to another Kubernetes cluster (B), so that when the apply an IrisCluster to B the Operator works remotely on A and plans the cluster accordingly on B. This design keeps some resource heat off the actual workload cluster, spares us some serviceaccounts/rbac and gives us only one operator deployment to worry about so we can concentrate on the IRIS workloads.
.png)
If you are in the business of building a robust High Availability, Disaster Recovery or Stamping multiple environments rapidly and in a consistent manner Karmada may just be the engine powering your Cloning Facility.
.png)
Rancher Government Hauler streamlines deploying and maintaining InterSystems container workloads in air-gapped environments by simplifying how you package and move required assets. It treats container images, Helm charts, and other files as content and collections, letting you fetch, store, and distribute them declaratively or via CLI — without changing your existing workflows. Meaning your charts and what have yous, can have conditionals on your pull locations in Helm values, etc.
If you have been tracking how HealthShare is being deployed via IPM Packages, you can certainly appreciate the adoption of OCI compliance storage for the packages themselves using ORAS... which is core to the Hauler solution.
The Istio Service Mesh is commonly used to monitor communication between services in applications. The "battle-tested" sidecar mode is its most common implementation. It will add a sidecar container to each pod you have in your namespace that has Istio sidecar injection enabled.
It's quite easy to get started with, just put the istioctl executable in your PATH, and label your namespace such that it tells Istio to acitvate side car injection there.
.png)
KWOK, Kubernetes WithOut Kubelet, is a lightweight tool that simulates nodes and pods—without running real workloads—so you can quickly test and scale IrisCluster behavior, scheduling, and zone assignment. For those of you wondering what value is in this without the IRIS workload, you will quickly realize it when you play with your Desk Toys awaiting nodes and pods to come up or get the bill for provisioning expensive disk behind the pvc's for no other reason than just to validate your topology.
Here we will use it to simulate an IrisCluster and target a topology across 4 zones, implementing high availability mirroring across zones, disaster recovery to an alternate zone, and horizontal ephemeral compute (ecp) to a zone of its own. All of this done locally, suitable for repeatable testing, and a valuable validation check mark on the road to production.
For a variety of reasons, users may wish to mount a persistent volume on two or more pods spanning multiple availability zones. One such use case is to make data stored outside of IRIS available to both mirror members in case of failover.
.png)
I am giving this distraction the code name "Compliment Sandwich" for a reason yet to be realized, but I'd rather the community go right for the jugular shooting holes in a solution that implements wireguard based connectivity for our workloads in general, as I would like to refine it as a fall project leading up to KubeCon in Atlanta and if I miss the mark, Ill get it done before Amsterdam.
.png)
Though trivial, Id like to go multi-cloud with the stretched IrisCluster for a couple of reasons to socialize the power of Wireguard when it supplies the network for a properly zoned IrisCluster by adding another mirror role to Amazon Web Services in the Western United States based datacenter in Oregon.
For a variety of reasons, users may wish to mount a persistent volume on two or more pods spanning multiple availability zones. One such use case is to make data stored outside of IRIS available to both mirror members in case of failover.
For a variety of reasons, users may wish to mount a persistent volume on two or more pods spanning multiple availability zones. One such use case is to make data stored outside of IRIS available to both mirror members in case of failover.
IAM - InterSystems API Manager is a great tool for monitoring your traffic. If you are trying to use it in your Kubernetes cluster you may have tried doing a deployment similar to this one:
apiVersion: intersystems.com/v1alpha1
kind: IrisCluster
metadata:
name: iris
spec:
licenseKeySecret:
name: iris-key-secret
configSource:
name: iris-cpf
imagePullSecrets:
- name: intersystems-pull-secret
topology:
data:
image: containers.intersystems.com/intersystems/iris-arm64:2024.1"2024.1.2"#InterSystems Demo Games entry
Kubernetes horizontal pod auto-scaling (HPA) is the key to handle the unpredictable compute workload in healthcare systems. IKO helps orchestrating the IRIS container deployment in Kubernetes including the capability to configure HPA. This demo uses XSLT processing as an example to showcase this type of elasticity.
🗣 Presenter: @Simon Sha, Sales Architect, InterSystems
InterSystems Kubernetes Operator (IKO) 3.8 is now Generally Available. IKO 3.8 adds new functionality along with numerous bug fixes and security updates. Highlights include:
Follow the Installation Guide for guidance on how to download, install, and get started with IKO. The complete IKO 3.8 documentation
Just like a knockout punch, without giving the opponent a chance, Kubernetes, as an open source platform, has a universe of opportunities due to its availability (i.e., the ease of finding support, services and tools). It is a platform that can manage jobs and services in containers, which greatly simplifies the configuration and automation of these processes.
But let's justify the title image and give the tool in question the “correct” name: InterSystems Kubernetes Operator.
If you are a customer of the new InterSystems IRIS® Cloud SQL and InterSystems IRIS® Cloud IntegratedML® cloud offerings and want access to the metrics of your deployments and send them to your own Observability platform, here is a quick and dirty way to get it done by sending the metrics to Google Cloud Platform Monitoring (formerly StackDriver).
Regardless of whether an instance of IRIS is in the cloud or not, high availability and disaster recovery are always important considerations. While IKO already allows for the use of NodeSelectors to enforce the scheduling of IRISCluster nodes across multiple zones, multi-region k8s clusters are generally not recommended or even supported in the major CSP's managed Kubernetes solutions. However, when discussing HA and DR for IRIS, we may want to have an async member in a completely separate region, or even in a different cloud provider altogether.
If you look at the values.yaml of the IKO's Helm chart you'll find:
useIrisFsGroup:falseLet's break down what it is and in what situations you may want to set it to true.
FsGroup refers to the file system group.
By default, Kubernetes volumes are owned by root, but we need IRIS to own its files (IRIS in containers is installed under irisowner user). To get around this we employ one of two methods:
The initContainers run before app containers (like IRIS) in a pod. They generally set up the environment for the application and then run to completion/terminate.
As an IT and cloud team manager with 18 years of experience with InterSystems technologies, I recently led our team in the transformation of our traditional on-premises ERP system to a cloud-based solution. We embarked on deploying InterSystems IRIS within a Kubernetes environment on AWS EKS, aiming to achieve a scalable, performant, and secure system. Central to this endeavor was the utilization of the AWS Application Load Balancer (ALB) as our ingress controller.
The IKO will dynamically provision storage in the form of persistent volumes and pods will claim them via persistent volume claims.
But storage can come in different shapes and sizes. The blueprint to the details about the persistent volumes comes in the form of the storage class.
This raises the question: we've deployed the IrisCluster, and haven't specified a storage class yet. So what's going on?
You'll notice that with a simple
kubectl get storageclassyou'll find the storage classes that exist in your cluster.
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:
#