Skip to content

Local Kind ingress

If you have deployed the local kind cluster as outlined on the create a local cluster page, follow these instructions to use an ingress for accessing your products.


  • A kind cluster deployed with ingress enabled. For this guide, the cluster name ping is assumed
  • The hostname aliases have been appended to the /etc/hosts file
  • You have created the secret for your DevOps user and key for retrieving licenses


With the /etc/hosts file entries created from the page linked above, the release in helm must be myping for the hostnames to work with the configuration here. Consider the first entry as an example: ...

When using our charts, the release name provided to helm is prepended - that is what provides the myping- portion of the hostname in the file. The domain suffix is provided through the ingress definitions as shown later on this page. So, the structure is:


If you use a release name other than myping or a domain other than you will need to update the aliases in /etc/hosts/ accordingly.


There is a file under the 30-helm directory of this repository named ingress.yaml. Modify this file for use with a local cluster:

  • Replace insert domain name here with your domain name ( in this guide)
  • Edit line 11, removing the -public suffix for the class

The file should look as shown here:

    enabled: true
    addReleaseNameToHost: prepend
    defaultDomain: ""
    annotations: "HTTPS" "nginx"

Create ingresses

When deploying using helm and one of the example YAML files in the 30-helm directory, also pass in the ingress.yaml file to include the ingress definitions as part of the overall deployment.

For example, to use the everything.yaml and include ingresses, you would run the following command from the 30-helm directory (after updating the ingress.yaml file):

helm upgrade --install myping pingidentity/ping-devops -f everything.yaml -f ingress.yaml

After everything has started, you will see the same pods and services as in the getting started example. In addition, you will see ingress definitions in the same namespace as the products:

# List ingress definitions
kubectl get ingress

# Output
NAME                         CLASS    HOSTS                                       ADDRESS     PORTS     AGE
myping-pingaccess-admin      <none>      localhost   80, 443   47m
myping-pingaccess-engine     <none>     localhost   80, 443   47m
myping-pingauthorize         <none>         localhost   80, 443   47m
myping-pingdataconsole       <none>       localhost   80, 443   47m
myping-pingdirectory         <none>         localhost   80, 443   47m
myping-pingfederate-admin    <none>    localhost   80, 443   47m
myping-pingfederate-engine   <none>   localhost   80, 443   47m

The HOSTS column reflects the entries added to the /etc/hosts file.

To access a given service, enter the HOSTS entry in your browser (you will have to accept the self-signed certificate). For example, to view the Ping Federate console, you would access For the Ping Data console, and so on.

Here are the credentials and URLs. This table is similar to the getting started example but reflects the release name used on this page:

Product Connection Details

Cleaning up

Since the ingresses are deployed as part of the overall release, deleting the release will also remove the ingress definitions (leaving the ingress controller intact).

The ingress controller will be removed when the cluster is deleted. If you only want to remove the ingress controller, you can either:

  • Run kubectl delete -f if you installed the controller from Github


  • Run kubectl delete -f ./20-kubernetes/kind-nginx.yaml if you used the local copy to install the controller.