The purpose of this document is to present how Kubernetes Service is supported by the kuryr integration and to capture the design decisions currently taken by the kuryr team.
A Kubernetes Service is an abstraction which defines a logical set of Pods and a policy by which to access them. Service is a Kubernetes managed API object. For Kubernetes-native applications, Kubernetes offers an Endpoints API that is updated whenever the set of Pods in a Service changes. For detailed information please refer to Kubernetes service Kubernetes supports services with kube-proxy component that runs on each node, Kube-Proxy.
Kubernetes service in its essence is a Load Balancer across Pods that fit the service selection. Kuryr’s choice is to support Kubernetes services by using Neutron LBaaS service. The initial implementation is based on the OpenStack LBaaSv2 API, so compatible with any LBaaSv2 API provider. In order to be compatible with Kubernetes networking, Kuryr-Kubernetes makes sure that services Load Balancers have access to Pods Neutron ports. This may be affected once Kubernetes Network Policies will be supported. Oslo versioned objects are used to keep translation details in Kubernetes entities annotation. This will allow future changes to be backward compatible.
Kubernetes service is mapped to the LBaaSv2 Load Balancer with associated Listeners and Pools. Service endpoints are mapped to Load Balancer Pool members.
Two Kubernetes Event Handlers are added to the Controller pipeline.
Both Handlers use Project, Subnet and SecurityGroup service drivers to get details for service mapping. LBaaS Driver is added to manage service translation to the LBaaSv2-like API. It abstracts all the details of service translation to Load Balancer. LBaaSv2Driver supports this interface by mapping to neutron LBaaSv2 constructs.
Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.