#Kubernetes

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 our previous article, we have explored the most common Kubernetes components:

• We started with the pods and the services we needed to communicate with each other.
• Then, we examined the Ingress component used to Route traffic into the cluster.
• We also skimmed through an external configuration using ConfigMaps and Secrets.
• Afterward, we analyzed Data persistence with the help of Volumes.
• Finally, we took a quick look at pod blueprints with such replicating mechanisms as Deployments and StatefulSets (the latter is employed specifically for such stateful applications as databases).

In this article, we will explore Kubernetes architecture and configuration.

I attended Cloud Native Security Con in Seattle with full intention of crushing OTEL day, then perusing the subject of security applied to Cloud Native workloads the following days leading up to CTF as a professional excercise. This was happily upended by a new understanding of eBPF, which got my screens, career, workloads, and atitude a much needed upgrade with new approaches to solving workload problems.

So I made it to the eBPF party and have been attending clinic after clinic on the subject ever since, here I would like to "unbox" eBPF as a technical solution, mapped directly to what we do in practice (even if its a bit off), and step through eBPF through my experimentation on supporting InterSystems IRIS Workloads, particularly on Kubernetes, but not necessarily void on standalone workloads.

eBee Steps with eBPF and InterSystems IRIS Workloads

So if you are following from the previous post or dropping in now, let's segway to the world of eBPF applications and take a look at Parca, which builds on our brief investigation of performance bottlenecks using eBPF, but puts a killer app on top of your cluster to monitor all your iris workloads, continually, cluster wide!

Continous Profiling with Parca, IRIS Workloads Cluster Wide

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.

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.

Good morning dear community,

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.