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)
Open Data Hub (ODH) is a blueprint for building an AI-as-a-Service (AIaaS) platform on Red Hat OpenShift 4. Version 0.7 of Open Data Hub includes support for deploying Kubeflow 1.0 on OpenShift, as well as increased component testing on the OpenShift continuous integration (CI) system. This article explores the recent updates.
Continue reading Open Data Hub 0.7 adds support for Kubeflow 1.0
Prometheus is an open source monitoring solution that collects metrics from the system and its applications. As a developer, you can query these metrics and use them to create alerts, which you can use as a source for dashboards. One example would be using Prometheus metrics with Grafana.
Continue reading Monitoring .NET Core applications on Kubernetes
Red Hat Advanced Cluster Management (ACM) for Kubernetes offers end-to-end visibility and control for managing your cluster and application lifecycle. Among other features, it ensures security and compliance for your entire Kubernetes domain across multiple data centers and public clouds.
Continue reading Installing Red Hat Advanced Cluster Management (ACM) for Kubernetes
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
Each new release of Red Hat OpenShift includes usability improvements and features to help developers meet their goals. In OpenShift 4.5, we’ve improved navigation and added a mechanism for customizing navigation and accessing frequently used resources from the Developer perspective.
Continue reading What’s new in the OpenShift 4.5 console developer experience
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”
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”
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
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
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”
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”