This featured was introduced as a pre-release in
Kubernetes steps in Octopus are of alpha level quality and have been made available for testing and feedback purposes only. They must not be used for production deployments, or enabled on production Octopus instances. The information provided here is subject to change at any point, and existing Kubernetes steps will most likely need to be deleted and recreated with Octopus upgrades.
Ingress resources provide a way to direct HTTP traffic to Service resources based on the requested host and path.
Each Ingress resource must have a unique name, defined in the
Ingress name field.
Ingress Host Rules
Ingress resources configure routes based on the host that the request was sent to. New hosts can be added by clicking the
Add Host Rule button.
Host field defines the host where the request was sent to. This field is optional and if left blank will match all hosts.
Add Path button adds a new mapping between a request path and the Service resource port.
Path field is the path of the request to match. It must start with a
Service Port field is the port from the associated Service resource that the traffic will be sent to.
Service Name field is the name of the associated service to direct the traffic to.
Ingress resources only provide configuration. A Ingress Controller resource uses the Ingress configuration to direct network traffic within the Kubernetes cluster.
There are many Ingress Controller resources available. Nginx is a popular option, that is used by the Azure AKS service. Google Cloud provides its own Ingress Controller resource. A third party Ingress Controller resource is available for AWS making use of the ALB service.
The diagram below shows a typical configuration with Ingress and Ingress Controller resources.
There is no standard behavior to the creation of load balancers when configuring Ingress Controller resources.
For example, the Google Cloud Ingress Controller will create a new load balancer for every Ingress resource. The documentation suggests to create a single Ingress resource to achieve a fanout pattern that shares a single load balancer.
On the other hand, the Nginx Ingress Controller resource installation procedure creates a single LoadBalancer Service resource that is shared by default.
Each of these different implementations is configured through the Ingress resource annotations. Annotations are key value pairs, and the values assigned to them depend on the Ingress resource that is being configured. The list below links to the documentation that describes the supported annotations.
A new annotation is defined by clicking the
Add Annotation button.
Name field will provide suggested annotation names, but this list of suggestions is not exhaustive, and any name can be added.
Value field defines the annotation value.
Annotation values are always considered to be strings. See this GitHub issue for more information.
Service Name defines the name of the Service resource that this Ingress will send traffic to.
When there are no matching ingress rules, traffic can be sent to the service configured as the default rule. The
Port field defines the service port that traffic will be sent to, and the
Service name defines the name of the Service resource to send traffic to.
Labels are optional name/value pairs that are assigned to the Ingress resource.