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”
After many months of waiting, Apache Camel K 1.0 is finally here! This groundbreaking project introduces developers to cloud-native application development and automated cloud configurations without breaking a sweat. With the 1.0 general availability (GA) release, Apache Camel K is more stable than ever, with performance improvements that developers will appreciate.
Continue reading “Camel K 1.0: The serverless integration platform goes GA”
It’s your first day as a Java programmer, right out of college. You have received your badge, a shiny new laptop, and all of your software requests have been approved. Everything seems to be going well.
You install Eclipse and set up the required Java Development Kit (JDK) in your new development environment. You clone a project from the company’s GitHub repository, modify the code, and make your first commit. You are excited to be working on your first project.
But then, a few hours later, a senior programmer asks what version of the JDK you used. It seems that the pipeline is reporting a project failure. All you did was commit Java source code, not binary, and it worked perfectly on your local machine. What could possibly have gone wrong?
Coding in a restricted environment
The issue I described is well-known among programmers as the “It works on my computer, and I don’t know why it doesn’t work on your computer” problem. Fortunately, this is the type of problem Red Hat CodeReady Workspaces (CRW) can help you solve. CodeReady Workspaces is a cloud-based IDE based on Che. Whereas Che is an open source project, CRW is an enterprise-ready development environment that provides the security, stability, and consistency that many corporations require. All you have to do is open the CRW link in a web browser, sign in with your user credentials, and code inside the browser.
In this article, I show you how to install CodeReady Workspaces in a restricted Red Hat OpenShift 4 environment.
Continue reading “How to install CodeReady Workspaces in a restricted OpenShift 4 environment”