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.
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:
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.
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.
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.
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.
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:
https://www.youtube.com/embed/GUbe6Iwt9T4 [This is an embedded link, but you cannot view embedded content directly on the site because you have declined the cookies necessary to access it. To view embedded content, you would need to accept all cookies in your Cookies Settings]
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.
Unfortunately the built-in storage classes in most Kubernetes implementations (whether cloud or on-prem) do not provide this capability:
This is like my first post in this community. Let's see how this turns out. I have a question about the Intersystems Kubernetes Operator and the deployment of the webgateways.
I am responsible for the hosting and deployment of the apps. For the future we are planning to host our application in a kubernetes cluster. I am using the IKO for this. I am using webgateways, for external access as separate pods. And sidecar containers for internal access, like the management portal.
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.
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.
https://www.youtube.com/embed/npCs5_yX_xg [This is an embedded link, but you cannot view embedded content directly on the site because you have declined the cookies necessary to access it. To view embedded content, you would need to accept all cookies in your Cookies Settings]
A step by step implementation path to a cross regional stretched IrisCluster with Mirroring using the Intersystems Kubernetes Operator (IKO), Google Cloud Platform, and Tailscale.
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.
Year
Open Exchange app
.png)
.png)