waiting for service external ip assignment

Kubernetes Service External IP Stuck on Pending? Here’s How to Fix It

25th April 2024 2 min read

Have you ever encountered a situation where your Service’s external IP address stubbornly stays in “pending” mode? We’ve all been there. In this post, we’ll delve into this common Minikube issue and explore two effective solutions to get that external IP up and running.

Understanding the LoadBalancer Service

In Kubernetes, the LoadBalancer service type shines when you need to expose network applications to the external world. It’s ideal for scenarios where you want a dedicated IP address assigned to each service.

On public cloud platforms like AWS or Azure, the LoadBalancer service seamlessly deploys a network load balancer in the cloud. However, Minikube takes a different approach. It simulates a load balancer using the tunnel protocol, and by default, the service’s external IP gets stuck on “pending.”

Setting Up the Example

Before diving into solutions, let’s set up a simple example using namespaces and deployments:

Create a Namespace:

Deploy a redis pod:, verify the pod:.

This creates a namespace (lbservice) and deploys a Redis pod within it. We’ll use this example to showcase exposing the Redis server externally.

Fixing the Pending External IP

Now, let’s tackle that pesky “pending” status! Here are two methods to assign an external IP address to the LoadBalancer service in Minikube:

Method 1: Using Minikube Tunnel

The LoadBalancer service thrives when the cluster supports external load balancers. While Minikube doesn’t provide a built-in implementation, it allows simulating them through network routes. Here’s how:

Create a LoadBalancer Service:

Check the external ip:.

You’ll see the “EXTERNAL-IP” column showing “”. Don’t worry, we’ll fix that!

Establish the Minikube Tunnel:

This command sets up network routes using the load balancer emulator.

Verify the IP Again:

Now you should see a newly allocated external IP address. That’s your gateway to the Redis server!

Access the Redis Server (Optional):

Replace with the actual IP you obtained. If everything’s configured correctly, you’ll receive a “PONG” response, indicating successful communication.

Method 2: Using MetalLB Addon

Similar to the tunnel approach, MetalLB is another load balancer option for assigning external IPs. Minikube offers an addon specifically for MetalLB, allowing easy configuration. Here’s how to use it:

Enable the MetalLB Addon:

Verify addon status:.

This ensures the addon is up and running.

Configure MetalLB (Optional):

By default, MetalLB uses a specific IP range. To customize this, find the Minikube node’s IP address using minikube ip and then run:

Specify the desired IP address range during the configuration process.

The “EXTERNAL-IP” column should now display an IP address within the configured range.

Use the service’s external IP address obtained in step 5 to connect to the Redis server using redis-cli.

Cleaning Up

Method 1 cleanup (tunnel):.

In the first terminal window, press Ctrl + C to terminate the tunnel process and remove network routes.

Delete the service:

Method 2 cleanup (metallb):.

Important Note: The provided cleanup steps involve deleting the entire namespace, which is suitable for testing environments only. In production, avoid bulk deletions and target specific resources.

This blog post explored two effective solutions to address the “pending” external IP issue in Minikube’s LoadBalancer services: the tunnel protocol and the MetalLB addon. Remember, the best approach depends on your specific needs and environment.

Feel free to experiment and choose the method that best suits your Kubernetes journey! And as always, if you have any questions or comments, don’t hesitate to reach out to us. Happy Deployments!

Have Queries? Join https://launchpass.com/collabnix

error: multiple platforms feature is currently not supported for…

Ollama Meets AMD GPUs: Leveraging ROCm for Faster LLM…

Running ollama with nvidia gpu acceleration: a docker compose….

Exposing an External IP Address to Access an Application in a Cluster

This page shows how to create a Kubernetes Service object that exposes an external IP address.

Before you begin

• Install kubectl .
• Use a cloud provider like Google Kubernetes Engine or Amazon Web Services to create a Kubernetes cluster. This tutorial creates an external load balancer , which requires a cloud provider.
• Configure kubectl to communicate with your Kubernetes API server. For instructions, see the documentation for your cloud provider.
• Run five instances of a Hello World application.
• Create a Service object that exposes an external IP address.
• Use the Service object to access the running application.

Creating a service for an application running in five pods

Run a Hello World application in your cluster:

The preceding command creates a Deployment and an associated ReplicaSet . The ReplicaSet has five Pods each of which runs the Hello World application.

Display information about the Deployment:

Display information about your ReplicaSet objects:

Create a Service object that exposes the deployment:

Display information about the Service:

The output is similar to:

Display detailed information about the Service:

Make a note of the external IP address ( LoadBalancer Ingress ) exposed by your service. In this example, the external IP address is 104.198.205.71. Also note the value of Port and NodePort . In this example, the Port is 8080 and the NodePort is 32377.

In the preceding output, you can see that the service has several endpoints: 10.0.0.6:8080,10.0.1.6:8080,10.0.1.7:8080 + 2 more. These are internal addresses of the pods that are running the Hello World application. To verify these are pod addresses, enter this command:

Use the external IP address ( LoadBalancer Ingress ) to access the Hello World application:

where <external-ip> is the external IP address ( LoadBalancer Ingress ) of your Service, and <port> is the value of Port in your Service description. If you are using minikube, typing minikube service my-service will automatically open the Hello World application in a browser.

The response to a successful request is a hello message:

Cleaning up

To delete the Service, enter this command:

To delete the Deployment, the ReplicaSet, and the Pods that are running the Hello World application, enter this command:

What's next

Learn more about connecting applications with services .

Was this page helpful?

Thanks for the feedback. If you have a specific, answerable question about how to use Kubernetes, ask it on Stack Overflow . Open an issue in the GitHub Repository if you want to report a problem or suggest an improvement .

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

How we can assign External IP's to our service in kubernetes with metallb

I have created a cluster using kubeadm with two azure virtual machines(one master and one node). Now i need external IP's for service LoadBalancer, i am using metalLB for assinging external IP's. I need the IP's from azure i.e virtual machines that i have created. Please do the needful.

Azure Virtual Network An Azure networking service that is used to provision private networks and optionally to connect to on-premises datacenters. 2,171 questions Sign in to follow

Azure Kubernetes Service (AKS) An Azure service that provides serverless Kubernetes, an integrated continuous integration and continuous delivery experience, and enterprise-grade security and governance. 1,872 questions Sign in to follow

??????????????????????????????????????????????

Hello kanav sharma ,

We haven’t heard from you on the last response and was just checking back to see if you have a resolution yet. In case if you have any resolution please do share that same with the community as it can be helpful to others. Otherwise, will respond with more details and we will try to help

Hi @kanav sharma

Did you get a chance to check the response from @Anveshreddy Nimmala ? If it helped, please confirm.

NO @Prrudram-MSFT Still my issue is not resolved. Please assign someone

This comment has been deleted due to a violation of our Code of Conduct. The comment was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

Welcome to Microsoft Q&A Platform, thanks for posting your query here.

1.Create a new Public IP address in Azure portal or using Azure CLI.

az network public-ip create --name <your-ip-name> --resource-group <your-resource-group> --allocation-method Static --sku Standard

2.Get the IP address of the Public IP address you just created in portal or by azure CLI.

az network public-ip show --name <your-ip-name> --resource-group <your-resource-group> --query ipAddress --output tsv

3.Create a new config map for MetalLB.

4.Create a new service of type LoadBalancer.

5.Wait for the external IP address to be assigned.

Hopes this answer is helpful, Please accept the answer for community purpose.

If an answer has been helpful, please consider accepting the answer to help increase visibility of this question for other members of the Microsoft Q&A community. If not, please let us know what is still needed in the comments so the question can be answered. Thank you for helping to improve Microsoft Q&A!.

suppose I want to create many pods. so I have to create a specific public IP in Azure for a specific pod. It will be time-consuming to create a public ip's for the pods. Is there any option we have like we can give public ip range so when we create a pod and a service (Load Balancer) It will automatically pick ip address from that range that we have given. so we can easily assign external ip's to create high numbers of pod. Is there any solution for that?

Anveshreddy Nimmala

please provide me the config map for the same.

Thankyou for replying back,

yes, you can use Azure Public IP address prefix to associate a range of public IP addresses to your Kubernetes services.

This will allow you to assign external IP addresses to a large number of pods without having to create individual public IP addresses for each pod.

1.Create an Azure Public IP address prefix. use this document to create public IP prefix.

https://learn.microsoft.com/en-us/azure/virtual-network/ip-services/public-ip-address-prefix

2.Create a Kubernetes Service of type LoadBalancer.

replace my-resource group with your azure resource group

replace my-service with your service name

replace 80 and 8080 with port you want expose and target port

3.Wait for the Azure Load Balancer to get created.

kubectl get service my-service -w

4Once Azure Load Balancer creation completes, the EXTERNAL-IP will be available.

NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE

my-service LoadBalancer 10.0.68.83 20.81.108.180 80:31523/TCP 18s

Hope this Answer helps you , please accept the answer if it is helpful for community purpose so that it can help others, else post back if any query we will work on it to provide better solution.

In config map for metallb what range i have to assign. please provide me config map configuration file also.

I have created a service after creating an Azure public IP prefix with a specific public IP range. and follow the same steps that you have provided but still facing an issue. No external IP is assigned for my service. I have also done an AZ login for the same but still facing an issue. Is there any other way we can add a virtual network CIDR range in the metallb configuration or service file with annotations Is there any issue with metallb config map level or with service file annotations? Please provide the steps briefly so that I can perform step by step.

thankyou for replying back with your Query.

please re-configure using this configmap.yaml

and Service.yaml files.

Hope this helps you.

I am still getting the same error. My external IP is still pending. I am assuming that the solution you provided is verified on your side because I am getting the same error every time. Please provide me with a detailed solution after verifying on your side.

Hello kanav sharma , thankyou for replying back Apologies for the inconvenience this issue may have caused. Support team will be able to check and help on this. I would recommend you to open a azure support case. If you don't have a support plan enabled on your subscription, I request you to send an email to [email protected] with Subject as "Attn:Vikas" referencing this thread along with your subscription ID. He can then enable your subscription with a one-time free technical support. Once the issue is resolved, request you to post the resolution here for the benefit of community.

I need assistance with the same. I mailed but no reply yet.

Hello kanav sharma , thankyou for replying back. As this issue additional investigation and work i have guide you to technical support. please raise a support ticket. Support team will be able to help on this. I would recommend you to open a azure support case. If you don't have a support plan enabled on your subscription, I request you to send an email to [email protected] with Subject as "Attn:Priyanka" referencing this thread along with your subscription ID. She can then enable your subscription with a one-time free technical support. Once the issue is resolved, request you to post the resolution here for the benefit of community.

Detailed walkthroughs of common Kubernetes operations and workflows.

Edit This Page

Exposing an External IP Address to Access an Application in a Cluster

This page shows how to create a Kubernetes Service object that exposees an external IP address.

Before you begin

Creating a service for an application running in five pods, cleaning up, what’s next.

• Run five instances of a Hello World application.
• Create a Service object that exposes an external IP address.
• Use the Service object to access the running application.

You need to have a Kubernetes cluster, and the kubectl command-line tool must be configured to communicate with your cluster. If you do not already have a cluster, you can create one by using Minikube .

Run a Hello World application in your cluster:

The preceding command creates a Deployment object and an associated ReplicaSet object. The ReplicaSet has five Pods , each of which runs the Hello World application.

Display information about the Deployment:

Display information about your ReplicaSet objects:

Create a Service object that exposes the deployment:

Display information about the Service:

The output is similar to this:

, wait for a minute and enter the same command again.

Display detailed information about the Service:

Make a note of the external IP address exposed by your service. In this example, the external IP address is 104.198.205.71. Also note the value of Port. In this example, the port is 8080.

In the preceding output, you can see that the service has several endpoints: 10.0.0.6:8080,10.0.1.6:8080,10.0.1.7:8080 + 2 more. These are internal addresses of the pods that are running the Hello World application. To verify these are pod addresses, enter this command:

Use the external IP address to access the Hello World application:

where <external-ip> us the external IP address of your Service, and <port> is the value of Port in your Service description.

The response to a successful request is a hello message:

To delete the Service, enter this command:

To delete the Deployment, the ReplicaSet, and the Pods that are running the Hello World application, enter this command:

Learn more about connecting applications with services .

Minikube: How to expose a service externally to the outside world (external IP)

Introduction.

Minikube is a popular tool to run Kubernetes locally. It’s a valuable resource for developers looking to test their applications before deploying to a production environment. In this tutorial, we will go over how to expose a service running on Minikube to the outside world using an external IP. This is crucial for the times when you want your local services to be accessible from an external network.

Setting Up Minikube

First and foremost, ensure that Minikube is installed on your machine. You can install it by following the official documentation here . Once installed, you can start a local Minikube cluster by executing:

Once the cluster is up, you’ll want to deploy a sample application to expose it externally. Let’s deploy a simple Hello World application using Kubectl:

Now, confirm that your deployment is running using:

Simple Service Exposure

To expose your application outside of the Kubernetes virtual network, you can create a Service of type NodePort or LoadBalancer. NodePort exposes the service on each Node’s IP at a static port, whereas the LoadBalancer enables you to use an external load balancer.

For Minikube, you’ll primarily use NodePort. Here is how you expose your deployment using NodePort:

Then, you can find the allocated port and IP by running:

This command outputs the URL that you can use to access your service from the browser or postman:

You’ve just exposed your first service. However, you might now need a stable external IP address rather than being bound to the one minikube assigns.

Using Minikube’s ‘tunnel’ Command

Minikube provides the tunnel command, which can help in allocating an external IP address that will route to a LoadBalancer service in your cluster. First, create a Service of type LoadBalancer:

Note: You may need to run the tunnel command with administrative privileges.

Running this command will give you an external IP to your service. Find it by calling:

Use the given EXTERNAL-IP to access your service through a web browser.

Advanced Exposing: Using Ingress

In a production-like environment, you might want a bit more control over how requests are routed to your services. Ingress is an API object that manages external access to services in a cluster, typically HTTP. Ingress can provide load balancing, SSL termination and name-based virtual hosting.

To make use of Ingress in Minikube, you must first enable the Ingress addon by running:

Then deploy an Ingress resource file that defines routing rules. Below is a basic example:

Note: Replace hello-world.info with the domain pointed to your Minikube IP.

To get the Minikube IP address, execute:

Once the Ingress resource is created, you can access your application through the domain specified in your Ingress configuration if you configure it in your /etc/hosts file or DNS.

Through this guide, you’ve learned how you can expose a service externally in Minikube. Whether you’re using a simple NodePort, LoadBalancer with the tunnel command or setting up an Ingress for more complex routing, Minikube is flexible to suit different development needs.

Next Article: How to Add and Manage Nodes in a Kubernetes Cluster

Previous Article: Kubernetes error: User 'system:serviceaccount:default:default' cannot get services in the namespace

Series: Kubernetes Tutorials

Related Articles

• Git: What is .DS_Store and should you ignore it?
• NGINX underscores_in_headers: Explained with examples
• How to use Jenkins CI with private GitHub repositories
• Terraform: Understanding State and State Files (with Examples)
• SHA1, SHA256, and SHA512 in Terraform: A Practical Guide
• CSRF Protection in Jenkins: An In-depth Guide (with examples)
• Terraform: How to Merge 2 Maps
• Terraform: How to extract filename/extension from a path
• JSON encoding/decoding in Terraform: Explained with examples
• Sorting Lists in Terraform: A Practical Guide
• Terraform: How to trigger a Lambda function on resource creation
• How to use Terraform templates

Search tutorials, examples, and resources

• PHP programming
• Symfony & Doctrine
• Laravel & Eloquent
• Tailwind CSS
• Sequelize.js
• Mongoose.js

• Documentation
• OpenShift Container Platform 4.15 4.14 4.13 4.12 4.11 4.10 4.9 4.8 4.7 4.6 4.5 4.4 4.3 4.2 4.1 3.11 3.10 3.9 3.7 3.6 3.5 3.4 3.3 3.2 3.1 3.0
• Developer Guide
• Getting Traffic into a Cluster
• Using a Service ExternalIP
• About OpenShift Container Engine
• Legal Notice
• OpenShift Container Platform 3.11 Release Notes
• xPaaS Release Notes
• Comparing with OpenShift Enterprise 2
• Install OpenShift
• Configure OpenShift
• Web Console Walkthrough
• Command-Line Walkthrough
• Kubernetes Infrastructure
• Container Registry
• Web Console
• Containers and Images
• Pods and Services
• Projects and Users
• Builds and Image Streams
• Deployments
• Authentication
• Authorization
• Persistent Storage
• Ephemeral Storage
• Source Control Management
• Admission Controllers
• Custom Admission Controllers
• Other API Objects
• OpenShift SDN
• Available SDN plug-ins
• Available router plug-ins
• Port Forwarding
• Remote Commands
• Service Catalog
• Service Catalog CLI
• Template Service Broker
• OpenShift Ansible Broker
• AWS Service Broker
• Introduction
• Container Hosts and Multi-tenancy
• Container Content
• Build Process
• Securing the Container Platform
• Network Security
• Attached Storage
• Monitoring Events and Logs
• Planning your installation
• System and environment requirements
• Preparing your hosts
• Configuring Your Inventory File
• Example Inventory Files
• Installing OpenShift
• Disconnected installation
• Installing a stand-alone deployment of OpenShift container image registry
• Uninstalling OpenShift
• Upgrade methods and strategies
• In-place upgrades
• Blue-green upgrades
• Updating operating systems
• Downgrading
• Internal Registry Overview
• Deploying a Registry on Existing Clusters
• Accessing the Registry
• Securing and Exposing the Registry
• Extended Registry Configuration
• Known Issues
• Router Overview
• Using the Default HAProxy Router
• Deploying a Customized HAProxy Router
• Configuring the HAProxy Router to Use the PROXY Protocol
• Requirements
• Configuring Role Variables
• Running the Installer
• Enabling Container Provider Integration
• Uninstalling
• Prometheus Cluster Monitoring
• Accessing and Configuring the Red Hat Registry
• Master and Node Configuration
• OpenShift Ansible Broker Configuration
• Adding Hosts to an Existing Cluster
• Loading the Default Image Streams and Templates
• Configuring Custom Certificates
• Redeploying Certificates
• Configuring Authentication and User Agent
• Syncing groups with LDAP
• Configuring LDAP failover
• Configuring the SDN
• Configuring Nuage SDN
• Configuring NSX-T SDN
• Configuring Kuryr SDN
• Configuring for AWS
• Configuring for Red Hat Virtualization
• Configuring for OpenStack
• Configuring for Google Compute Engine
• Configuring for Azure
• Configuring for VMware vSphere
• Configuring Local Volumes
• Using GlusterFS
• Using OpenStack Cinder
• Using Ceph RBD
• Using AWS Elastic Block Store
• Using GCE Persistent Disk
• Using iSCSI
• Using Fibre Channel
• Using Azure Disk
• Using Azure File
• Using FlexVolume
• Using VMware vSphere volumes for persistent storage
• Using Local Volume
• Using Container Storage Interface (CSI)
• Using OpenStack Manila shares
• Dynamic Provisioning and Creating Storage Classes
• Volume Security
• Selector-Label Volume Binding
• Enabling Controller-managed Attachment and Detachment
• Persistent Volume Snapshots
• Using hostPath
• Sharing an NFS PV Across Two Pods
• Using Ceph RBD for Persistent Storage
• Using Ceph RBD for dynamic provisioning
• Complete Example Using GlusterFS
• Complete Example Using GlusterFS for Dynamic Provisioning
• Mounting Volumes To Privileged Pods
• Mount Propagation
• Switching an Integrated OpenShift Container Registry to GlusterFS
• Binding Persistent Volumes by Label
• Using StorageClasses for Dynamic Provisioning
• Using StorageClasses for Existing Legacy Storage
• Configuring Azure Blob Storage for Integrated Container Image Registry
• Configuring Ephemeral Storage
• Working with HTTP Proxies
• Configuring Global Build Defaults and Overrides
• Configuring Pipeline Execution
• Configuring Route Timeouts
• Configuring Native Container Routing
• Routing from Edge Load Balancers
• Aggregating Container Logs
• Aggregate Logging Sizing Guidelines
• Enabling Cluster Metrics
• Customizing the Web Console
• Deploying External Persistent Volume Provisioners
• Installing the Operator Framework (Technology Preview)
• Uninstalling Operator Lifecycle Manager
• Run-once tasks
• Environment health checks
• Creating an environment-wide backup
• Host-level tasks
• Project-level tasks
• Docker tasks
• Managing Certificates
• Managing Nodes
• Restoring your cluster
• Replacing a master host
• Managing Users
• Managing Projects
• Managing Pods
• Managing Networking
• Configuring Service Accounts
• Managing Role-based Access Control
• Image Policy
• Image Signatures
• Scoped Tokens
• Monitoring Images
• Managing Security Context Constraints
• Default Scheduling
• Descheduling
• Custom Scheduling
• Controlling Pod Placement
• Pod Priority and Preemption
• Advanced Scheduling
• Advanced Scheduling and Node Affinity
• Advanced Scheduling and Pod Affinity/Anti-affinity
• Advanced Scheduling and Node Selectors
• Advanced Scheduling and Taints and Tolerations
• Setting Quotas
• Setting Multi-Project Quotas
• Pruning objects
• Extending the Kubernetes API with Custom Resources
• Garbage Collection
• Allocating Node Resources
• Overcommitting
• Out of Resource Handling
• Setting Limit Ranges
• Node Problem Detector
• Assigning Unique External IPs for Ingress Traffic
• Monitoring and Debugging Routers
• High Availability
• Securing Builds by Strategy
• Restricting Application Capabilities Using Seccomp
• Encrypting Data at Datastore Layer
• Encrypting traffic between nodes with IPsec
• Building Dependency Trees
• Replacing a failed etcd member
• Restoring etcd quorum
• Troubleshooting Networking
• Diagnostics Tool
• Idling Applications
• Analyzing Cluster Capacity
• Configuring the cluster auto-scaler in AWS
• Disabling Features using Feature Gates
• Kuryr SDN Administration
• Recommended Installation Practices
• Recommended Host Practices
• Optimizing Compute Resources
• Optimizing Persistent Storage
• Optimizing Ephemeral Storage
• Network Optimization
• Routing Optimization
• Scaling Cluster Metrics
• Scaling Cluster Monitoring
• Tested Maximums per Cluster
• Using Cluster Loader
• Using CPU Manager
• Managing Huge Pages
• Optimizing On GlusterFS Storage
• Planning Your Development Process
• Creating New Applications
• Promoting Applications Across Environments
• Database Applications
• Web Framework Applications
• QuickStart Examples
• Continuous Integration and Deployment
• Webhooks and Action Hooks
• Support Guide
• Quickstart Templates
• Ruby on Rails
• Setting Up a Nexus Mirror
• OpenShift Pipeline Builds
• Binary Builds
• How Builds Work
• Basic Build Operations
• Build Inputs
• Build Output
• Build Strategy Options
• Build Environment
• Triggering Builds
• Build Hooks
• Build Run Policy
• Advanced Build Operations
• Troubleshooting
• How Deployments Work
• Basic Deployment Operations
• Deployment Strategies
• Advanced Deployment Strategies
• Kubernetes Deployments Support
• Opening a Remote Shell to Containers
• Service Accounts
• Managing Images
• Quotas and Limit Ranges
• Using a Router
• Using a Load Balancer
• Using a NodePort
• Integrating External Services
• Using Device Manager
• Using Device Plug-ins
• Downward API
• Projected Volumes
• Using Daemonsets
• Pod Autoscaling
• Managing Volumes
• Using Persistent Volumes
• Expanding Persistent Volumes
• Executing Remote Commands
• Copying Files
• Shared Memory
• Application Health
• Managing Environment Variables
• OpenShift Pipeline
• Create from URL
• Creating an object from a custom resource definition
• Application memory sizing
• Application ephemeral storage sizing
• Image Metadata
• S2I Requirements
• Testing S2I Images
• Custom Builder
• Customizing S2I Images
• Jenkins Slaves
• Other Container Images
• Get Started with the CLI
• Managing CLI Profiles
• Developer CLI Operations
• Administrator CLI Operations
• Differences Between oc and kubectl
• Extending the CLI
• CLI Tooling
• Getting Started
• Binding [core/v1]
• ComponentStatus [core/v1]
• ConfigMap [core/v1]
• Endpoints [core/v1]
• Event [core/v1]
• LimitRange [core/v1]
• Namespace [core/v1]
• Node [core/v1]
• PersistentVolumeClaim [core/v1]
• PersistentVolume [core/v1]
• Pod [core/v1]
• PodTemplate [core/v1]
• ReplicationController [core/v1]
• ResourceQuota [core/v1]
• Secret [core/v1]
• ServiceAccount [core/v1]
• Service [core/v1]
• About admissionregistration.k8s.io
• MutatingWebhookConfiguration [admissionregistration.k8s.io/v1beta1]
• ValidatingWebhookConfiguration [admissionregistration.k8s.io/v1beta1]
• About apiregistration.k8s.io
• APIService [apiregistration.k8s.io/v1]
• ControllerRevision [apps/v1]
• DaemonSet [apps/v1]
• Deployment [apps/v1]
• ReplicaSet [apps/v1]
• StatefulSet [apps/v1]
• About apps.openshift.io
• DeploymentConfig [apps.openshift.io/v1]
• About authentication.k8s.io
• TokenReview [authentication.k8s.io/v1]
• About authorization.k8s.io
• LocalSubjectAccessReview [authorization.k8s.io/v1]
• SelfSubjectAccessReview [authorization.k8s.io/v1]
• SelfSubjectRulesReview [authorization.k8s.io/v1]
• SubjectAccessReview [authorization.k8s.io/v1]
• About authorization.openshift.io
• ClusterRoleBinding [authorization.openshift.io/v1]
• ClusterRole [authorization.openshift.io/v1]
• LocalResourceAccessReview [authorization.openshift.io/v1]
• LocalSubjectAccessReview [authorization.openshift.io/v1]
• ResourceAccessReview [authorization.openshift.io/v1]
• RoleBindingRestriction [authorization.openshift.io/v1]
• RoleBinding [authorization.openshift.io/v1]
• Role [authorization.openshift.io/v1]
• SelfSubjectRulesReview [authorization.openshift.io/v1]
• SubjectAccessReview [authorization.openshift.io/v1]
• SubjectRulesReview [authorization.openshift.io/v1]
• About autoscaling
• HorizontalPodAutoscaler [autoscaling/v1]
• About batch
• CronJob [batch/v1beta1]
• Job [batch/v1]
• About build.openshift.io
• BuildConfig [build.openshift.io/v1]
• Build [build.openshift.io/v1]
• About certificates.k8s.io
• CertificateSigningRequest [certificates.k8s.io/v1beta1]
• About events.k8s.io
• Event [events.k8s.io/v1beta1]
• About image.openshift.io
• Image [image.openshift.io/v1]
• ImageSignature [image.openshift.io/v1]
• ImageStreamImage [image.openshift.io/v1]
• ImageStreamImport [image.openshift.io/v1]
• ImageStreamMapping [image.openshift.io/v1]
• ImageStream [image.openshift.io/v1]
• ImageStreamTag [image.openshift.io/v1]
• About network.openshift.io
• ClusterNetwork [network.openshift.io/v1]
• EgressNetworkPolicy [network.openshift.io/v1]
• HostSubnet [network.openshift.io/v1]
• NetNamespace [network.openshift.io/v1]
• About networking.k8s.io
• NetworkPolicy [networking.k8s.io/v1]
• About oauth.openshift.io
• OAuthAccessToken [oauth.openshift.io/v1]
• OAuthAuthorizeToken [oauth.openshift.io/v1]
• OAuthClientAuthorization [oauth.openshift.io/v1]
• OAuthClient [oauth.openshift.io/v1]
• About policy
• PodDisruptionBudget [policy/v1beta1]
• PodSecurityPolicy [policy/v1beta1]
• About project.openshift.io
• ProjectRequest [project.openshift.io/v1]
• Project [project.openshift.io/v1]
• About quota.openshift.io
• AppliedClusterResourceQuota [quota.openshift.io/v1]
• ClusterResourceQuota [quota.openshift.io/v1]
• About rbac.authorization.k8s.io
• ClusterRoleBinding [rbac.authorization.k8s.io/v1]
• ClusterRole [rbac.authorization.k8s.io/v1]
• RoleBinding [rbac.authorization.k8s.io/v1]
• Role [rbac.authorization.k8s.io/v1]
• About route.openshift.io
• Route [route.openshift.io/v1]
• About scheduling.k8s.io
• PriorityClass [scheduling.k8s.io/v1beta1]
• About security.openshift.io
• PodSecurityPolicyReview [security.openshift.io/v1]
• PodSecurityPolicySelfSubjectReview [security.openshift.io/v1]
• PodSecurityPolicySubjectReview [security.openshift.io/v1]
• RangeAllocation [security.openshift.io/v1]
• SecurityContextConstraints [security.openshift.io/v1]
• About storage.k8s.io
• StorageClass [storage.k8s.io/v1]
• VolumeAttachment [storage.k8s.io/v1beta1]
• About template.openshift.io
• BrokerTemplateInstance [template.openshift.io/v1]
• Template [template.openshift.io/v1]
• TemplateInstance [template.openshift.io/v1]
• About user.openshift.io
• Group [user.openshift.io/v1]
• Identity [user.openshift.io/v1]
• UserIdentityMapping [user.openshift.io/v1]
• User [user.openshift.io/v1]
• Using the CRI-O Container Engine
• Container-native Virtualization Installation
• Container-native Virtualization Users Guide
• Container-native Virtualization Release Notes

Using a Service External IP to Get Traffic into the Cluster

Defining the public ip range, create a project and service, expose the service to create a route, assigning an ip address to the service, configuring networking, configure ip failover using vips.

One method to expose a service is to assign an external IP access directly to the service you want to make accessible from outside the cluster.

Make sure you have created a range of IP addresses to use, as shown in Defining the Public IP Address Range .

By setting an external IP on the service, OpenShift Container Platform sets up IP table rules to allow traffic arriving at any cluster node that is targeting that IP address to be sent to one of the internal pods. This is similar to the internal service IP addresses, but the external IP tells OpenShift Container Platform that this service should also be exposed externally at the given IP. The administrator must assign the IP address to a host (node) interface on one of the nodes in the cluster. Alternatively, the address can be used as a virtual IP (VIP) .

These IPs are not managed by OpenShift Container Platform and administrators are responsible for ensuring that traffic arrives at a node with this IP.

This process involves the following:

The administrator performs the prerequisites ;

The developer creates a project and service , if the service to be exposed does not exist;

The developer exposes the service to create a route .

The developer assigns the IP address to the service .

The network administrator configures networking to the service .

Administrator Prerequisites

Before starting this procedure, the administrator must:

Set up the external port to the cluster networking environment so that requests can reach the cluster. For example, names can be configured into DNS to point to specific nodes or other IP addresses in the cluster. The DNS wildcard feature can be used to configure a subset of names to an IP address in the cluster. This allows the users to set up routes within the cluster without further administrator attention.

Make sure that the local firewall on each node permits the request to reach the IP address.

Configure the OpenShift Container Platform cluster to use an identity provider that allows appropriate user access.

Make sure there is at least one user with cluster-admin role. To add this role to a user, run the following command:

Have an OpenShift Container Platform cluster with at least one master and at least one node and a system outside the cluster that has network access to the cluster. This procedure assumes that the external system is on the same subnet as the cluster. The additional networking required for external systems on a different subnet is out-of-scope for this topic.

The first step in allowing access to a service is to define an external IP address range in the master configuration file:

Log in to OpenShift Container Platform as a user with the cluster admin role.

Configure the externalIPNetworkCIDRs parameter in the /etc/origin/master/master-config.yaml file as shown:

For example:

Restart the OpenShift Container Platform master service to apply the changes.

If the project and service that you want to expose do not exist, first create the project, then the service.

If the project and service already exist, go to the next step: Expose the Service to Create a Route .

Log in to OpenShift Container Platform.

Create a new project for your service:

Use the oc new-app command to create a service :

Run the following command to see that the new service is created:

By default, the new service does not have an external IP address.

You must expose the service as a route using the oc expose command.

To expose the service:

Log in to the project where the service you want to expose is located.

Run the following command to expose the route:

On the master, use a tool, such as cURL, to make sure you can reach the service using the cluster IP address for the service:

The examples in this section use a MySQL service, which requires a client application. If you get a string of characters with the Got packets out of order message, you are connected to the service.

If you have a MySQL client, log in with the standard CLI command:

Then, perform the following tasks:

Assign an IP Address to the Service

Configure networking

Configure IP Failover

To assign an external IP address to a service:

Load the project where the service you want to expose is located. If the project or service does not exist, see Create a Project and Service in the Prerequisites.

Run the following command to assign an external IP address to the service you want to access. Use an IP address from the external IP address range :

The <name> is the name of the service and -p indicates a patch to be applied to the service JSON file. The expression in the brackets will assign the specified IP address to the specified service.

Run the following command to see that the service has a public IP:

On the master, use a tool, such as cURL, to make sure you can reach the service using the public IP address:

If you get a string of characters with the Got packets out of order message, you are connected to the service.

After the external IP address is assigned, you need to create routes to that IP.

The following steps are general guidelines for configuring the networking required to access the exposed service from other nodes. As network environments vary, consult your network administrator for specific configurations that need to be made within your environment.

On the master:

Restart the network to make sure the network is up.

If the network is not up, you will receive error messages such as Network is unreachable when running the following commands.

Run the following command with the external IP address of the service you want to expose and device name associated with the host IP from the ifconfig command output:

If you need to, run the following command to obtain the IP address of the host server where the master resides:

Look for the device that is listed similar to: UP,BROADCAST,RUNNING,MULTICAST .

Add a route between the IP address of the host where the master resides and the gateway IP address of the master host. If using a netmask for a networking route, use the netmask option, as well as the netmask to use:

The netstat -nr command provides the gateway IP address:

Add a route between the IP address of the exposed service and the IP address of the master host:

On the Node:

If the network is not up, you will receive error messages such as Network is unreachable when executing the following commands.

Add a route between IP address of the host where the node is located and the gateway IP of the node host. If using a netmask for a networking route, use the netmask option, as well as the netmask to use:

The ifconfig command displays the host IP:

The netstat -nr command displays the gateway IP:

Add a route between the IP address of the exposed service and the IP address of the host system where the master node resides:

Use a tool, such as cURL, to make sure you can reach the service using the public IP address:

If you get a string of characters with the Got packets out of order message, your service is accessible from the node.

On the system that is not in the cluster:

Add a route between the IP address of the remote host and the gateway IP of the remote host. If using a netmask for a networking route, use the netmask option, as well as the netmask to use:

Add a route between the IP address of the exposed service on master and the IP address of the master host:

If you get a string of characters with the Got packets out of order message, your service is accessible outside the cluster.

Optionally, an administrator can configure IP failover .

IP failover manages a pool of Virtual IP (VIP) addresses on a set of nodes. Every VIP in the set is serviced by a node selected from the set. As long as a single node is available, the VIPs will be served. There is no way to explicitly distribute the VIPs over the nodes. As such, there may be nodes with no VIPs and other nodes with multiple VIPs. If there is only one node, all VIPs will be on it.

The VIPs must be routable from outside the cluster.

Navigation Menu

Search code, repositories, users, issues, pull requests..., provide feedback.

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly.

To see all available qualifiers, see our documentation .

• Notifications

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement . We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CreatingLoadBalancerFailed :timed out waiting for the condition #26124

g0pinath commented Mar 4, 2019

Sorry, something went wrong.

mimckitt commented Mar 4, 2019

jakaruna-MSFT commented Mar 4, 2019

G0pinath commented mar 5, 2019.

• 👍 1 reaction

No branches or pull requests