Vendor the base# Run these commands from the root of your Kubestack infra repositorywget https://storage.googleapis.com/catalog.kubestack.com/nginx-v0.46.0-kbst.0.zipunzip -d manifests/bases/ nginx-v0.46.0-kbst.0.ziprm nginx-v0.46.0-kbst.0.zip
Include resource in apps overlaycd manifests/overlays/appskustomize edit add resource ../../bases/nginx/default-ingress
Commit and pushcd -git checkout -b add-nginxgit add manifests/bases/nginx manifests/overlays/apps/kustomization.yamlgit commit -m "Add nginx v0.46.0-kbst.0 base"git push origin add-nginx
Review PR and merge
Finally, review and merge the PR into master. Once it's been successfully applied against the Ops-Cluster set a prod-deploy tag to also apply the change against the Apps-Cluster.
To update the operator delete the previously vendored base and then vendor the new version.
Delete the previous vendored version# Run these commands from the root of your Kubestack infra repositoryrm -r manifests/bases/nginx
Vendor the new version# Run these commands from the root of your Kubestack infra repositorywget https://storage.googleapis.com/catalog.kubestack.com/nginx-v0.46.0-kbst.0.zipunzip -d manifests/bases/ nginx-v0.46.0-kbst.0.ziprm nginx-v0.46.0-kbst.0.zip
Commit and pushgit checkout -b update-nginxgit add manifests/bases/nginxgit commit -m "Update nginx base to v0.46.0-kbst.0"git push origin update-nginx
Operators often create resources based on custom objects. When removing an operator, follow a two-step process to ensure operator provisioned resources are purged properly.
- Remove all the operator's custom objects.
- Once the operator had time to de-provision all resources it created, follow the instructions below to remove the operator itself.
Remove resource from apps overlaycd manifests/overlays/appskustomize edit remove resource ../../bases/nginx/default-ingress
Delete the vendored base from your repositorycd -# Run these commands from the root of your Kubestack infra repositoryrm -r manifests/bases/nginx
Commit and pushgit checkout -b remove-nginxgit add manifests/bases/nginxgit commit -m "Remove nginx base"git push origin remove-nginx
With the Nginx ingress controller deployed to the Kubernetes cluster, you can use it to expose services outside of the cluster.
The included DNS zone is used for host-based routing in the example below. However, for user-facing applications, consider using a CNAME record to point your domain to the cluster's FQDN and then do host-based routing on your domain.
Kubernetes Ingress Resource
To configure how your service is exposed through Nginx ingress, use a Kubernetes' built-in ingress resource. Below is an example ingress resource that routes HTTP requests based on the host header to a specific service inside the cluster. For more details about the configuration options, please refer to the official documentation.
To get started, put the example below into a file called
ingress.yaml and add it to your application's manifests.
apiVersion: extensions/v1beta1kind: Ingressmetadata:# CHANGE MEname: example-appnamespace: example-appspec:rules:# CHANGE ME- host: appname.kbst-apps-us-east1.gcp.infra.example.comhttp:paths:- backend:# CHANGE MEserviceName: example-appservicePort: 80
Next, adapt the
serviceName in the example above to the cluster FQDN you set up at the end of the quickstart and the name of the service of the application you want to expose.
Finally, apply the manifests including the
ingress.yaml as usual.
Nginx Ingress Annotations
Nginx ingress exposes a number of Nginx configuration options and features including redirects, authentication and more that are not part of the Kubernetes ingress definition. These additional parameters can be configured by setting annotations. Please refer to the Nginx ingress documentation for a list of available annotations.