In the first article of the series, we went through the reasons why a Service Mesh could be useful as part of your architecture.
In this article, we are going to start configuring the Service Mesh to better understand one of its main benefits that we talked about at that moment: the advanced routing. You can use this capability to modify the behavior of your application without having to include external pieces as an API gateway or additional code in your microservices.
I will touch on some of the Control Plane and Data Plane concepts that we already reviewed, so…
In the previous article, we have seen some of the most important Service Mesh Control Plane aspects, now it’s the time for the Data Plane.
If you want to review the Control Plane part jump to:
Or if you want to start from the beginning:
Or start playing with some examples that show the Service Mesh features:
In this article, we are going to explore the OpenShift Service Mesh Data Plane. The idea here is to learn about the Data Plane by showing how to publish a Service Mesh application but without using the extended Istio features (ie. smart routing…
In this second article, we will go through the preparation and deployment of the OpenShift Service Mesh Control Plane. You will see the different configuration options used while deploying your Service Mesh Control Planes, including how you should set it up for production environments (spoiler: that’s not the default configuration), and how to deploy them in your OpenShift cluster.
I will try to include a little bit more information than the current official OpenShift Documentation, but mostly all content of this article can be found there. …
In this series of articles, we will dig into the OpenShift Service Mesh world. In this first post we will go through some introductory questions like “Why someone would need a Service Mesh?“, “Do I really need it?”, “How is the OpenShift Service Mesh architecture?”.
In the next articles, we will go through the steps to setup the OpenShift Service Mesh platform and start configuring and testing some of its main features. If you want to jump to the Control Plane installation and checks, take a look at the second article:
Or review any article of the OpenShift Service Mesh…
This is the final post about how to configure Security Zones in your OpenShift workers. You should already complete the previous configuration steps:
This time we will configure RBAC and other restrictions to allow only a subset of our OpenShift cluster users being able to use the Secure Zone.
Now everything is working. We could say that we have done, but only if we fully trust our OpenShift users, since any user can choose when to deploy workloads in the Secure Zone.
We don’t want that. We, as cluster administrators, want to setup certain namespaces, attached to some users/groups, that…
In this post we will focus on the network configuration needed to split ingress and egress traffic in our Security Zones. We will also configure an additional network to be used for direct access from the PODs (secondary interface in Multus).
You should go through the previous steps before start configuring this part:
The next step in our configuration is to split the network traffic. Remember that we started from this setup:
This is the second part of the series about how to create Security Zones in your OpenShift workers. If you missed the introduction take a look at it:
As the first configuration step, we will create two differentiated groups of workers.
First, we need a way to group the worker nodes for the new Zone. We need to go from the default architecture…
In this post series, you will see how to split your OpenShift workers into multiple Security Zones.
I don’t want this post to be a “quick-guide to”. I will explain a lot of details, options, explanations, tips&tricks, worst-case scenarios, caveats, tests, day2 ops, etc… and that’s why it’s SO LONG…
This is more intended to be read by people that want to know more about Kubernetes/OpenShift infrastructure in general with the excuse of creating Security Zones in worker nodes, more than for those ones that want to check a quick review about how to perform the actual configuration. …
This Post extends the “Enhanced Platform Awareness (EPA) in OpenShift” series by presenting the Performance Addon Operator, which configures many of the “EPA features” that we reviewed in the past Posts, but without having to configure them separately, and includes additional tunings to the Worker node Operating System that makes it better to accommodate performant deterministic workloads.
Note: This Post is slightly different from the previous ones, where we were using General Availability or Technology Preview OpenShift 4.4 features, in this case we try to show the capabilities that will be available in near future with OpenShift and that will…
Welcome to Part IV!, If you want to review the previous Posts about how to configure EPA in OpenShift 4 (4.4):
Or if you want to take a look at the “Bonus Track” Post regarding the new Performance Addon Operator:
With EPA features we are looking to reduce uncertainty about latency and jitter, along with improving performance when possible (remember that sometimes the more than you get a deterministic environment the fewer overall performance you obtain). …
I was born some time ago, I’m living daily and, probably, I will eventually die