---
# System prepended metadata

title: Use a controller to deploy and manage the lifecycle of peer pod components

---

# Use a controller to deploy and manage the lifecycle of peer pod components

## Problem:
To run Peer Pods several components (cloud-api-adaptor, webhook, cert-manager) need to be started and kept running. In addition configuration settings like the extened resources need to be added. All of this makes the peer pod environment a stateful application. Managing stateful applications is what Operators are made for.

- How to make sure the overall state is always correct?
Individual components like the cloud-api-adaptor are guaranteed to keep running because of Kubernetes' core controllers. However there is no higher order controller that makes sure all components are up and running, that its configuration is up-to-date and everything is (un)deployed in the correct order.

- How to integrate peer pods in e.g. the CoCo operator?
Currently the coco operator and peer pods are somehow two separate projects but they also have dependencies.  

## Idea:
Use a separate and new controller and a CRD to manage the lifecycle of the overall peer pods solution. Integration of cloud-api-adaptor, the webhook and setting up the extended resources into an existing operator, like the Confidential Containers operator, could be simplified by bundling everything into a [controller](https://kubernetes.io/docs/concepts/architecture/controller/). The controller is the glue between all involved components and business logic.

This controller could be imported by an operator and integrated with a few lines of code (see README of my RFC implementation, link below).

By containing all Peer Pod logic in a controller, the risk for operators that want to integrate Peer Pod functionality could be reduced. For example adding a boolean to an existing CRD (Custom Resource Definition) would gate the Peer Pod code. Enabling the option in the CR instance would launch the peer pod controller code.

The peer-pod-controller will support one additional CRD
As an additional improvement to user experience a CustomResource could help to centralize configuration settings etc. in one place and also serve as a trigger for deploying/undeploying.

I have started an implementation, which is in an early state but should give an idea of what I have in mind: https://github.com/jensfr/peer-pod-controller

I wanted to share it early and get the communities feedback. Depending on it I can send a PR. 





