Operator

OpenShift joins the Argo CD community (KubeCon Europe 2020)

OpenShift joins the Argo CD community (KubeCon Europe 2020)

As Kubernetes and Red Hat OpenShift platform adoption grow and organizations move a larger portion of their infrastructure to these platforms, organizations are increasingly faced with the challenge of managing hybrid multicluster environments across the public cloud and on-premises infrastructure. While this approach brings flexibility and scalability to managing applications, the ability to ensure configuration consistency across these clusters, and the ability to roll out applications to multiple clusters in a consistent manner becomes a necessity. Enter the Argo CD GitOps Kubernetes Operator.

Continue reading OpenShift joins the Argo CD community (KubeCon Europe 2020)

Share
Open Data Hub and Kubeflow installation customization

Open Data Hub and Kubeflow installation customization

The main goal of Kubernetes is to reach the desired state: to deploy our pods, set up the network, and provide storage. This paradigm extends to Operators, which use custom resources to define the state. When the Operator picks up the custom resource, it will always try to get to the state defined by it. That means that if we modify a resource that is managed by the Operator, it will quickly replace it to match the desired state.

Continue reading Open Data Hub and Kubeflow installation customization

Share
Performance and usability enhancements in Red Hat CodeReady Workspaces 2.2

Performance and usability enhancements in Red Hat CodeReady Workspaces 2.2

Red Hat CodeReady Workspaces 2.2 is now available. For the improvements in this release, we focused on performance and configuration, plus updating CodeReady Workspaces 2.2 to use newer versions of the most popular runtimes and stacks. We also added the ability to allocate only the CPU that you need for IDE plugins, and we introduced a new diagnostic feature that lets you start up a workspace in debug mode.

CodeReady Workspaces 2.2 is available on OpenShift 3.11 and OpenShift 4.3 and higher, including tech-preview support for OpenShift 4.5.

Note: Based on Eclipse Che, CodeReady Workspaces is a Red Hat OpenShift-native developer environment that supports cloud-native development.

Continue reading “Performance and usability enhancements in Red Hat CodeReady Workspaces 2.2”

Share
Kourier: A lightweight Knative Serving ingress

Kourier: A lightweight Knative Serving ingress

Until recently, Knative Serving used Istio as its default networking component for handling external cluster traffic and service-to-service communication. Istio is a great service mesh solution, but it can add unwanted complexity and resource use to your cluster if you don’t need it.

That’s why we created Kourier: To simplify the ingress side of Knative Serving. Knative recently adopted Kourier, so it is now a part of the Knative family! This article introduces Kourier and gets you started with using it as a simpler, more lightweight way to expose Knative applications to an external network.

Let’s begin with a brief overview of Knative and Knative Serving.

Continue reading “Kourier: A lightweight Knative Serving ingress”

Share
Migrating a namespace-scoped Operator to a cluster-scoped Operator

Migrating a namespace-scoped Operator to a cluster-scoped Operator

Within the context of Kubernetes, a namespace allows dividing resources, policies, authorization, and a boundary for cluster objects. In this article, we cover two different types of Operators: namespace-scoped and cluster-scoped. We then walk through an example of how to migrate from one to the other, which illustrates the difference between the two.

Namespace-scoped and cluster-scoped

A namespace-scoped Operator is defined within the boundary of a namespace with the flexibility to handle upgrades without impacting others. It watches objects within that namespace and maintains Role and RoleBinding for role-based access control (RBAC) policies for accessing the resource.

Meanwhile, a cluster-scoped Operator promotes reusability and manages defined resources across the cluster. It watches all namespaces in a cluster and maintains ClusterRole and ClusterRoleBinding for RBAC policies for authorizing cluster objects. Two examples of cluster-scoped operators are istio-operator and cert-manager. The istio-operator can be deployed as a cluster-scoped to manage the service mesh for an entire cluster, while the cert-manager is used to issue certificates for an entire cluster.

These two types of Operators support both types of installation based on your requirements. In the case of a cluster-scoped Operator, upgrading the Operator version can impact resources managed by the Operator in the entire cluster, as compared to upgrading the namespace-scoped Operator, which will be easier to upgrade as it only affects the resource within its scope.

Continue reading “Migrating a namespace-scoped Operator to a cluster-scoped Operator”

Share
A development roadmap for Open Data Hub

A development roadmap for Open Data Hub

Open Data Hub (ODH) is a blueprint for building an AI-as-a-Service (AIaaS) platform on Red Hat’s Kubernetes-based OpenShift 4.x. The Open Data Hub team recently released Open Data Hub 0.6.0, followed up by a smaller update of Open Data Hub 0.6.1.

We recently got together and discussed our plans and timeline for the next two releases. Our plans are based on the roadmap slide deck that we put together and presented during the Open Data Hub community meeting on April 6.

In this article, we present our roadmap for the next several Open Data Hub releases. We would like to emphasize that the target dates are optimistic, describing what we would like to achieve. With the current state of the world and vacation time coming up, these dates might change.

Continue reading “A development roadmap for Open Data Hub”

Share