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.
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.
In this article, we’ll build a highly available IRIS configuration using Kubernetes Deployments with distributed persistent storage instead of the “traditional” IRIS mirror pair. This deployment would be able to tolerate infrastructure-related failures, such as node, storage and Availability Zone failures. The described approach greatly reduces the complexity of the deployment at the expense of slightly extended RTO.
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.
Hi colleagues!
Every day Johns Hopkins University publishes new data on coronavirus COVID-19 pandemic status.
I built a simple InterSystems IRIS Analytics dashboard using InterSystems IRIS Community Edition in docker deployed on GCP Kubernetes which shows key measures of the disease outbreak.
This dashboard is an example of how information from CSV could be analyzed with IRIS Analytics and deployed to GCP Kubernetes in a form of InterSystems IRIS Community Edition.
Added the interactive map of the USA:
I am pleased to announce the availability of InterSystems Container Registry. This provides a new distribution channel for customers to access container-based releases and previews. All Community Edition images are available in a public repository with no login required. All full released images (IRIS, IRIS for Health, Health Connect, System Alerting and Monitoring, InterSystems Cloud Manager) and utility images (such as arbiter, Web Gateway, and PasswordHash) require a login token, generated from your WRC account credentials.
The IKO documentation is robust. A single web page, that consists of about 50 actual pages of documentation. For beginners that can be a bit overwhelming. As the saying goes: how do you eat an elephant? One bite at a time. Let's start with the first bite: helm.
What is Helm?
Helm is to Kubernetes what the InterSystems Package Manager (IPM, formerly ObjectScript Package Manager - ZPM) is to IRIS.
It facilitates the installation of applications on the platform - in a fashion suitable for Kubernetes.
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.
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.
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).
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.
If you look at the values.yaml of the IKO's Helm chart you'll find:
useIrisFsGroup: false Let'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.
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.
#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
We now get to make use of the IKO.
Below we define the environment we will be creating via a Custom Resource Definition (CRD). It lets us define something outside the realm of what the Kubernetes standard knows (this is objects such as your pods, services, persistent volumes (and claims), configmaps, secrets, and lots more). We are building a new kind of object, an IrisCluster object.
apiVersion: intersystems.
Want a commercial grade FHIR® Implementation included in your micro service ecosystem and barely have enough time to fill out your Health plan elections?
Here is a quick way to invite the InterSystems® FHIR®Accelerator Service to your Kubernetes Microservice party for immediate use. The solution uses Nginx proxy ninja moves to get the job done. Though rustic and bound to create some technical arguments, I am pretty happy with the results until this community tells me otherwise, so FHIR® away as they say but it would be great if you heard me out first.
IRIS configurations and user accounts contain various data elements that need to be tracked, and many people struggle to copy or sync those system configurations and user accounts between IRIS instances. So how can this process be simplified?
In software engineering, CI/CD or CICD is the set of combined practices of continuous integration (CI) and (more often) continuous delivery or (less often) continuous deployment (CD). Can CI/CD eliminate all our struggles?
I work in a team which develops and deploys IRIS clusters. We run IRIS in containers on Red Hat OpenShift container platform.
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
compatibilityVersion: "2024.1.All pods are assigned a Quality of Service (QoS). These are 3 levels of priority pods are assigned within a node.
The levels are as following:
1) Guaranteed: High Priority
2) Burstable: Medium Priority
3) BestEffort: Low Priority
It is a way of telling the kubelet what your priorities are on a certain node if resources need to be reclaimed. This great GIF below by Anvesh Muppeda explains it.
If resources need to be freed, firstly pods with Best Effort QoS will be evicted, then those with Burstable, and finally those with Guaranteed.
In this article, we will cover below topics:
Kubernetes is an open-source container orchestration framework developed by Google. In essence, it controls container speed and helps you manage applications consisting of multiple containers. Additionally, it allows you to operate them in different environments, e.g., physical machines, virtual machines, Cloud environments, or even hybrid deployment environments.
.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.
.png)
With the world (as well as our own technology) moving to the cloud at such a fast pace it is easy (at least for myself) to get caught up in the little details. One thing I, and some clients of ours, had run into a couple of times was the necessity to specify the version of the images one plans to use with the IKO.
For example, one issue that often gets overlooked is the compatibilityVersion field for the IKO. Depending on which IKO you are using there is a default value (for IKO 3.6 this happens to be 2023.2.0, and for IKO 3.5 this is 2022.3.0).
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.
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.
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.
This article will cover turning over control of provisioning the InterSystems Kubernetes Operator, and starting your journey managing your own "Cloud" of InterSystems Solutions through Git Ops practices. This deployment pattern is also the fulfillment path for the PID^TOO||| FHIR Breathing Identity Resolution Engine.
I encourage you to do your own research or ask your favorite LLM about Git Ops, but I can paraphrase it here for you as we understand it.
Introduction
Several resources tell us how to run IRIS in a Kubernetes cluster, such as Deploying an InterSystems IRIS Solution on EKS using GitHub Actions and Deploying InterSystems IRIS solution on GKE Using GitHub Actions. These methods work but they require that you create Kubernetes manifests and Helm charts, which might be rather time-consuming.
To simplify IRIS deployment, InterSystems developed an amazing tool called InterSystems Kubernetes Operator (IKO). A number of official resources explain IKO usage in details, such as New Video: Intersystems IRIS Kubernetes Operator and InterSystems Kubernetes Operator.
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.In this article, we’ll look at one of the ways to monitor the InterSystems IRIS data platform (IRIS) deployed in the Google Kubernetes Engine (GKE). The GKE integrates easily with Cloud Monitoring, simplifying our task. As a bonus, the article shows how to display metrics from Cloud Monitoring in Grafana.
Note that the Google Cloud Platform used in this article is not free (price list), but you can leverage a free tier. This article assumes that you already have a project in the Google Cloud Platform (referred to as <your_project_id>) and have permission to use it.
.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)