#Kubernetes

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

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.

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.

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

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).

Hey Community,

Hit that play button and enjoy the new video on InterSystems Developers YouTube:

⏯ Can You Autoscale This? Lessons from the Field on Kubernetes @ Global Summit 2023

https://www.youtube.com/embed/AjPUDGYyNsU
[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]

Hi, I was wondering if anyone already dealt with this issue:
"System has been suspended for over X seconds, exceeding the maximum duration specified. Allowing system activity to resume. Any ongoing backup has presumably failed. Next InterSystems IRIS backup must be a full one"

our backup system "Commvault" is automatic, how do you tell it once you get this message that the next backup should be full?

thanks,

Eyal

We have solution which uses IRIS with IAM and webgateway integrated.

After integration, we notice that in the kong configuration in the kongdb upstreams are not created as listed in the kong.yml

We noticed that, IAM api calls are failing with enterprise license expired.

[kong@iam-deployment-75f485954c-ssdfv /]$ curl --location --request POST 'http://localhost:8001/services/'
{"message":"Enterprise license missing or expired"}

From Logs:

K9s is a terminal-based UI (aka kubectl clown suit), to manage Kubernetes clusters that drastically simplifies navigating, observing, and managing your applications in K8s, including Custom Resources like the InterSystems Kubernetes Operator (IKO) and ArgoCD Applications. If you are about to take your CKD, CKA, or CKS, leave k9s well enough alone for awhile as the abstraction to kubectl will become the standard for navigating the cluster and you will undoubtedly become estranged to the extended flags of kubectl and bomb the exam.

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.

I want to deploy IRIS apps running in containers in Kubernetes with user accounts configured.

I have a %ZSTART routine which looks for an XML file with Users export data and if the %ZSTART routine finds this file, it imports it. This Users export data can be obtained by running a class method.

I have defined a task which can be scheduled or run on demand. This tasks imports user data from an XM file.

In Kubernetes I can provide a ConfigMap to stage the Users data for the %ZSTART routine.

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.

LS,

I'm trying to learn how to use the IKO for deploying solutions to Kubernetes. In my current project I'm trying to deploy the IAM onto a K8S context. Are there directly usable samples of the yaml file I need to use for that?