Pepijn Oomen
Platform Engineer, Redpill Linpro, Norway
Oslo, Norway
Actions
With 40+ years experience in the ICT field, Pepijn has been recognised by IBM as an OS/2 Warp Engineer and a Lotus Notes Principal Engineer, by RedHat as a Certified Engineer (RHCE) and a Certified Specialist in OpenShift and more recently by the Linux Foundation as a Kubestronaut.
He is a long time user of containers and Kubernetes and has previously been providing on-site trainings for RedHat OpenShift.
As a Platform Engineer, Pepijn works with a focus on security, reliability and automation for complex infrastructures.
Area of Expertise
Topics
Using cluster-api for declarative management of Kubernetes clusters
The Cluster API project uses Kubernetes-style APIs and patterns to automate cluster lifecycle management for platform operators. The supporting infrastructure, like virtual machines, networks, load balancers, and VPCs, as well as the Kubernetes cluster configuration are all defined in the same way that application developers operate deploying and managing their workloads. This enables consistent and repeatable cluster deployments across a wide variety of infrastructure environments.
In this presentation we will look at the way clusters are defined and show a deployment of a Talos Linux cluster on Openstack. We will also discuss the role of the bootstrap cluster, and how to perform a pivot to achieve a self-managed cluster.
Talos Linux: One (Immutable) OS to Rule Them All
Talos Linux is Linux designed for Kubernetes – secure, immutable, and minimal. It is based on a hardened kernel and a minimal user space, ie. no SSH, shell or console. All system management is done via a gRPC API.
In this presentation the audience will be introduced to Talos Linux and be shown how to get a full blown Kubernetes cluster up and running within minutes on a Cloud Platform, as well as on a developer workstation.
Beyond the Black Box: Kubernetes continuous deployments with the Rendered Manifest Pattern
Traditional application deployment to Kubernetes platforms typically relies upon ArgoCD or Flux, alongside tools like Kustomize, Helm, or Jsonnet. While this does the job, the "black box" nature of these rendering tools obscures the final manifests, making auditing and troubleshooting significantly more complex.
By adopting the Rendered Manifest Pattern (RMP), manifest construction is shifted from the deployment phase to the integration phase (shift-left). This approach removes the "magic" from the deployment process by ensuring that the code in your version control system directly reflects the state of the cluster. Consequently, this enhances transparency and streamlines both quality assurance and auditing.
In this session we will provide a comparison of the traditional pattern and the newly proposed pattern. By examining the advantages and limitations of both, the aim is to provide the audience with a deeper understanding of how the rendered manifest pattern can improve operational clarity and deployment reliability.
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top