Frequently Asked Questions (FAQs)

What is Container Ingress Services?

Container Ingress Services (CIS) is an F5 open-source solution being offered to support Ingress control (BIG-IP Next) app services in leading containerized and PaaS environments.

Container Ingress Services enables app self-service selection and service automation for DevOps’ containerized applications deployments. CIS integrates with the native container environment management/orchestration system, such as Kubernetes and Red Hat OpenShift platform as a service (PaaS).

What is the latest version of Container Ingress Services?

Refer to the BIG-IP Next CIS Release Notes for the latest available release version.

BIG-IP Next CIS releases are available for download from Docker Hub and RedHat Container Registry.

What platforms has it been validated on?

BIG-IP Next CIS is tested on the latest updates to Kubernetes, OpenShift, and F5 BIG-IP Next.

Refer to BIG-IP Next CIS cis-compatbility for CIS version and their compatability with Kubernetes, OpenShift, and F5 BIG-IP Next.

What are some limitations I should be aware of in BIG-IP Next CIS 20.3.0?

BIG-IP Next CIS 20.3.0 does not support all the BIG-IP Next features, Checkout the feature parity for each resource before proceeding.

What is the customer value proposition for Container Ingress Services?

Container Ingress Services delivers F5 inline integration for app performance and security services orchestration and management by native integrations with container environments. CIS enables self-service selection within orchestration management for container applications, and automated discovery and services insertion based on app events. In addition, CIS easily creates appropriate service configurations of the inline BIG-IP Next through BIG-IP Next Central Manager for Ingress control within container environments for performance, security, and management of container app traffic. Finally, CIS simplifies deployment in Helm Charts with pre-configured Kubernetes resources, and enables flexible deployment of OpenShift Routes with pre-existing configurations.

Who are the Target Customers?

Network architects, Network operations, AppDev, DevOps & System Infrastructure. Container Ingress Services provides the ability to expose BIG-IP services to NetOps, Network Architects’ customers, the application owners, and system infrastructure teams through their container management/orchestration system for self-service and standardization. Many times, NetOps aren’t able to keep up with the many container app service IT requests from AppDev/System teams for DevOps process. NetOps needs to provide through integration self-service and automation of app services within the container orchestration UI.

What are Container Ingress Services use cases?

  • Dynamic app services for container environments: The BIG-IP Next can have application level objects (VIPs, Pools, Pool Members) provisioned and managed from within the container orchestration environment, enabling auto-scaling of pool members up or down depending on app services demand.
  • Auto-scaling and security in cloud and on premises container environments: Self-service selection within the orchestration UI or automated app performance and security services based on event discovery for on premises and across cloud container applications.
  • Advanced container app protection Container Ingress Services integrated to BIG-IP Next and the container environment provides simplified and centralized app and network protection. Integrate with vulnerability assessment for patching and gain attack insights from F5 and data stream export to Prometheus, Splunk or SIEM/Analytics solution.
  • Streamline app migration and scale multiple app versions simultaneously: Blue/Green deployments for multiple app versions in Red Hat OpenShift PaaS for production at the same time for scaling and moving to newer applications. It provides A/B testing traffic management of two or more app versions in Red Hat OpenShift for development and testing at the same time.

What are the behavior changes for BIG-IP Next CIS 20.3.0?

CIS Behaviour Changes in version BIG-IP Next CIS 20.3.0 are:

  • How we deploy the BIG-IP Next CIS 20.3.0 has been changed, Please check the Installation for same.
  • BIG-IP Next CIS 20.3.0 posts the applications to the BIG-IP Next via BIG-IP Next Central Manager, While CIS 2.x directly posts the application to classic BIGIP.
  • BIG-IP Next CIS 20.3.0 can manage multiple BIG-IP Next instance and deploy the applications on multiple BIG-IP Next instances.
  • BIG-IP Next CIS 20.3.0 also updates it’s status in DeployConfig CR. See more details on “Troubleshooting CIS Configuration”.

Why does BIG-IP Next CIS need admin credentials?

BIG-IP Next CIS needs admin credentials because it requires administrative privileges to BIG-IP Next Central Manager to configure and deploy applications.

The BIG-IP Next Central Manager user account must have the appropriate role defined.

BIG-IP Next CIS also allows you to manage your BIG-IP Next Central Manager credentials and let you store and manage sensitive information in K8S secrets.

The credentials-directory option is an alternative to using the cm-username, cm-password, or cm-url arguments.

When you use this argument, the controller looks for three files in the specified directory: “username”, “password”, and “url”. If any of these files do not exist, the controller falls back to using the CLI arguments as parameters.

Each file should contain only the username, password, and URL, respectively. You can create and mount the files as Kubernetes Secrets.

Important

Do not project the Secret keys to specific paths, because the controller looks for the “username”, “password”, and “url” files directly within the credentials directory.

What is Ingress and how is it different than ingress?

Ingress with a capital “I” refers to HTTP Routing or a collection of rules to reach the cluster services. In addition, ingress, many times with a lower-case “i”, refers to inbound connections, app load balancing, and security services.

What happens when BIG-IP Next CIS pod crashes?

BIG-IP Next CIS is a control-plane and not a data-plane component. So traffic will not be impacted during a CIS outage and once a new replica is online, BIG-IP Next CIS will gather the state of the cluster and apply that to the associated F5 BIG-IP.

How do I deploy BIG-IP Next CIS in an air-gapped or disconnected environment?

Follow these steps to download and deploy BIG-IP Next CIS in an air-gapped or disconnected environments.

  1. Find the mirror registry and its authentication credentials to mirror the BIG-IP Next CIS release images.
  2. Pull the BIG-IP Next CIS image to the local environment using the command below.
$> docker pull docker.io/F5Networks/k8s-bigip-ctlr:latest
  1. Tag the image with the mirror registry URL.
$> docker tag docker.io/F5Networks/k8s-bigip-ctlr:latest
<--MIRROR-REGISTRY-URL-->/k8s-bigip-ctlr
  1. Login to the mirror registry and push the above tagged BIG-IP Next CIS release image.
$> docker login <--MIRROR-REGISTRY-URL-->/k8s-bigip-ctlr

$> docker push <--MIRROR-REGISTRY-URL-->/k8s-bigip-ctlr
  1. Update the BIG-IP Next CIS deployment to use release image from mirror registry.
containers:
- image: "<--MIRROR-REGISTRY-URL-->/k8s-bigip-ctlr"
  1. Update the ImagePullSecrets in the BIG-IP Next CIS deployment with credentials
    to access the mirror registry to pull above uploaded image if required.

Is BIG-IP Next HA supported by BIG-IP Next CIS?

No, CIS 3.0 is not validated with BIG-IP Next HA.


Note

To provide feedback on Container Ingress Services or this documentation, please file a GitHub Issue.