The Trireme implementation talks directly to the Kubernetes master without an external controller and receives notifications on policy updates and pod instantiations so that it can maintain a local cache of the policy and update the authorization rules as needed. There is no requirement for any shared state between Trireme components that needs to be synchronized. Trireme can be deployed either as a standalone process in every worker or by using [Daemon Sets](/docs/admin/daemons/). In the latter case, Kubernetes takes ownership of the lifecycle of the Trireme pods.
Trireme's simplicity is derived from the separation of security policy from network transport. Policy enforcement is linked directly to the labels present on the connection, irrespective of the networking scheme used to make the pods communicate. This identity linkage enables tremendous flexibility to operators to use any networking scheme they like without tying security policy enforcement to network implementation details. Also, the implementation of security policy across the federated clusters becomes simple and viable.
**Kubernetes and Trireme deployment**
Kubernetes is unique in its ability to scale and provide an extensible security support for the deployment of containers and microservices. Trireme provides a simple, secure, and scalable mechanism for enforcing these policies.
You can deploy and try Trireme on top of Kubernetes by using a provided Daemon Set. You'll need to modify some of the YAML parameters based on your cluster architecture. All the steps are described in detail in the [deployment GitHub folder](https://github.com/aporeto-inc/trireme-kubernetes/tree/master/deployment). The same folder contains an example 3-tier policy that you can use to test the traffic pattern.
To learn more, download the code, and engage with the project, visit:
- Trireme on [GitHub](https://github.com/aporeto-inc/trireme-kubernetes)
- Trireme for Kubernetes by Aporeto on [GitHub](https://github.com/aporeto-inc/trireme-kubernetes)