Namespace-Driven Inclusion/Exclusion of OpenShift/Kubernetes Applications

Starting with releases 17.1.9 and 17.2.4, Avi Vantage supports the inclusion or exclusion of applications to be proxied based on their membership within identified OpenShift/Kubernetes namespaces. Once inclusion/exclusion rules are established, they are automatically enforced on an ongoing basis. This feature can be accessed via the REST API or Avi UI; Avi UI support is planned for a future release.

How Application Inclusion/Exclusion by Namespace Works

Namespaces, Applications, and Labels

In OpenShift/Kubernetes, a set of applications lives within a namespace, which isolates the apps from those in other namespaces. Namespace isolation is such that app names can be re-used across namespaces with no risk of name clashes. Figure 1 depicts five namespaces (nsp1 through nsp5), each with its own set of applications (e.g., a1, a2, b1, c1 and so on). A namespace may optionally have labels associated with it. In this particular example, every namespace has at least two labels. The nsp1 namespace has three labels. Labels may take the form of {attribute:value} tuples, as in {sub : tools}, or can be defined by a single attribute, as in {beta}.

Namespaces and their associated labels Figure 1. OpenShift/Kubernetes namespaces contain applications and can optionally be labeled

Avi Vantage Tenants and Virtual Services

Via its cloud connector for OpenShift/Kubernetes, Avi Vantage will create tenants corresponding to OpenShift/Kubernetes namespaces, and in those tenants define virtual services corresponding to the namespaces’ applications. If Avi Vantage’s clusterrole is such that it has list, get, and watch access to all the namespaces, then Avi’s creation/deletion of tenants (with names like nsp1) and virtual services (with names like a1) will be governed by the labels assigned to namespaces by the OpenShift/Kubernetes administrator. For more information on clusterrole, read the Kubernetes Service Account for Avi Vantage Authentication article.

On the Avi Vantage side, ns_include_attributes and ns_exclude_attribute sub-commands refer to these OpenShift/Kubernetes labels. These sub-commands are used to insert include and exclude rules into the definition of the Avi Vantage OpenShift/Kubernetes cloud. The sub-commands are illustrated in a subsequent section. Figures 2a and 2b illustrate the impact of applying the rules established by those commands.

Labels to be included or excluded
Figure 2a. Labels to be included or excluded

Avi Vantage’s Interpretation of Labels

  • As depicted in Figure 2b, exclusion by the {department:mktg} label dominates over inclusion by the {sub:tools} label.
  • When a namespace has one or more labels, Avi Vantage’s treatment of it is governed by those labels. In an include operation, failure to match is an implicit exclusion. In an exclude operation, failure to match is an implicit include operation. When a namespace’s labels match both include and exclude operations, the exclude operation dominates.
  • It is possible but not recommended to omit labels from a namespace. Here’s why: Avi’s treatment of a label-free namespace is the opposite of the operation. That is:
    • In an include operation, the label-free namespace will be excluded.
    • In an exclude operation, the label-free namespace will be included. Such default behavior denies the administrator explicit control over the fate of label-free namespaces, and could yield unintended results.
  • Avi Vantage’s behavior with respect to OpenShift/Kubernetes namespaces and labels is dynamic. Changes made to the labels may have an immediate effect on the Avi Vantage side. For example, removal of the {department:mktg} label from namespace nsp6 would automatically trigger the creation of a tenant named nsp6, and thereafter creation of six virtual services (named a1 through a6).
OpenShift/Kubernetes namespaces selected by inclusion/exclusion of attributes
Figure 2b. OpenShift/Kubernetes namespaces selected by inclusion/exclusion of attributes

Configuration via the Avi CLI

Defining an OpenShift Multi-Inclusion Rule


configure cloud Default-Cloud
oshiftk8s_configuration
ns_include_attributes
attribute sub
value tools
save
ns_include_attributes
attribute department
value it
save
save
save

Defining an OpenShift Exclusion Rule


configure cloud Default-Cloud
oshiftk8s_configuration
ns_exclude_attributes
attribute department
value mktg
save
save
save