Dulek's Blog-
Kuryr - when to and when not to consider it
Kuryr-Kubernetes is a CNI plugin for Kubernetes, that uses OpenStack native networking layer - Neutron and Octavia, to provide networking for Pods and Services in K8s clusters running on OpenStack. While it’s a tempting concept to unify the networking layers of both OpenStack and Kubernetes and there are clear performance benefits, such setups also have a number of disadvantages that I’ll try to explain in this article.
-
type=LoadBalancer Services in Kuryr and cloud provider
type=LoadBalancerServicesare the backbone of many applications based on Kubernetes. They allow using cloud’s load balancer implementation to expose aServiceto the outside world. An alternative is usingIngress, but that might feel more complicated, requires running Ingress Controller and only works with HTTP, so often times you’re forced to use the hero of this post. Let’s then dive in into how it works with OpenStack as Kubernetes or OpenShift platform. -
CCM, cloud provider, CAPO, MAPO - OpenStack in OpenShift explained
Integrating an app with a cloud is a difficult thing in general, but when the app is called OpenShift and implements a whole container platform abstracting the underlying clouds, the task becomes a serious challenge. That’s why when researching the topic you might feel lost hearing acronyms like CAPO, MAPO or OCCM. This blog post’s goal is to explain roles of these integration points between OpenShift and OpenStack, the components implementing that integration and why this ended up so complicated. For a more detailed discussion of the integration you can check out the talk by my colleague Matt Booth presented at OpenInfra Summit in Berlin.
-
First post
Alright, so this is the first, test entry on the blog. Welcome, more content to follow soon. Meanwhile I’ll just put a random code snippet here to have a cheat sheet for later. And also to see how it looks like rendered.