The IKO container is distributed as both part of the IKO distribution and via the InterSystems Container Registry.  For most users, the right answer is to just point to the container in ICR.  We mention this in the documentation here:  https://docs.intersystems.com/irislatest/csp/docbook/DocBook.UI.Page.cls...

If you have your own container registry you can push the container there.  The error message provided looks like you're trying to add it to docker hub and getting permission denied. 

I think we need a bit more info about your data structure and your environment. 

I built the following little program on my mac with .NET 5  and it runs really fast (reported as 0 ms).  The data structure in my example, as you can see, is incredibly simple, so that might be the source of performance differences.  I'm also running on localhost, which could be different on your setup.

 

using System;
using InterSystems.Data.IRISClient;
using InterSystems.Data.IRISClient.ADO;

public class IRISNative
{
    public static void Main(String[] args) 
    {
        try {
            IRISConnection conn = new IRISConnection();
            conn.ConnectionString = "Server=localhost; Port=1972; Namespace=User; Password=...; User ID=...; SharedMemory=false; logfile=./dbnative.log";
            conn.Open();

            IRIS iris = IRIS.CreateIRIS(conn);

            Console.WriteLine("[1. Populating the data]");
            string global = "^testGlobal";
            object[] Subs = new object[1];
            Subs[0] = "node1";

            var watch = new System.Diagnostics.Stopwatch();
            watch.Start();
            for (var i=0; i<50; i++) {
                iris.Set(i, global, Subs[0], "node"+i);
            }
            watch.Stop();
            Console.WriteLine($"Execution Time: {watch.ElapsedMilliseconds} ms");

            Console.WriteLine("[2. Querying the data]");
            watch = new System.Diagnostics.Stopwatch();
            watch.Start();
            IRISIterator iter = iris.GetIRISIterator(global, Subs);
            foreach (var item in iter)
            {
                Console.WriteLine((string)(iter.CurrentSubscript));
            }
            watch.Stop();
            Console.WriteLine($"Execution Time: {watch.ElapsedMilliseconds} ms");

            iris.Close();
            conn.Close();
        }
        catch (Exception ex)
        {
            Console.WriteLine(ex.Message);
        }
    }
}

We've tried to package up our best practices for deploying IRSI in K8s into the InterSystems Kubernetes Operator.  In other words, instead of documenting everything, we built a tool that automates what can be automated.

That said, it doesn't cover everything.  Your example question is a good one - should IRIS clusters be deployed into the same kubernetes cluster as your other workloads?  The right answer to that depends on your exact needs.

In general, you shouldn't deploy IRIS into a different Kubernetes cluster than the rest of your kubernetes-managed application.  However, I'd consider doing it if there were strong architectural/compliance reasons to keep the IRIS cluster separated from other applications.  

Feel free to reach out if you want someone to go over your situation give more proscriptive advice.

Hi Stefan - 

I'll try to answer your questions in order.  If you want to know more, let me know.

  • IKO does not currently configure any kubernetes ingress, but there is a service that is configured which you could choose to configure for external access (a load balancer, for example).  You can set this via spec.serviceTemplate.spec section of your iriscluster yaml.  That's a spec which gives details about the service that we create.  I like to use ClusterIP for the service type and then create an ingress to give me good control over what is exposed to the internet.  A bit more info can be found here:  https://kubernetes.io/docs/concepts/services-networking/service/#publish...
  •  
  • Regarding routing to individual hosts... From within the cluster (say another pod in the namespace) each other pod is accessible via it's hostname (for example, myCluster-data-0-1) and you can use the kubectl port forwarding feature to allow you administrative access as you may need.  For non-administrative workflows, I suggest creating kubernetes services that point to the subset(s) of pods you want to use for each type of production traffic you want to manage.
  •  
  • We are currently working on adding native support for IAM and SAM in IKO, which greatly simplifies installing these products in Kubernetes.  In the meantime, most use cases would want to run IAM inside the cluster by creating a series of kubernetes deployments, services, and ingress to deploy IAM.  I might be able to gin up an example if you're going this way.  

Hi Yuri - 

It just so happens that Josh and I will be demoing that exact feature as part of the InterSystems IRIS 2020.1 webinar series on Tuesday.  Come join us!  Ask me hard questions!  No wait, ask me really easy questions! :)

https://event.on24.com/eventRegistration/EventLobbyServlet?target=reg20.jsp&referrer=&eventid=2389926&sessionid=1&key=623FAFE670B06BD7A6DC580BA91DE326&regTag=&sourcepage=register