Support pathType field in the Ingress resource

deployments/helm-chart/templates/rbac.yaml

@@ -62,7 +62,7 @@ rules:
   - patch
   - list
 - apiGroups:
-  - extensions
+  - networking.k8s.io
   resources:
   - ingresses
   verbs:

deployments/rbac/rbac.yaml

@@ -4,7 +4,7 @@ metadata:
   name: nginx-ingress
 rules:
 - apiGroups:
-  - ""
+  - "networking.k8s.io"
   resources:
   - services
   - endpoints
@@ -46,15 +46,15 @@ rules:
   - patch
   - list
 - apiGroups:
-  - extensions
+  - "networking.k8s.io"
   resources:
   - ingresses
   verbs:
   - list
   - watch
   - get
 - apiGroups:
-  - "extensions"
+  - "networking.k8s.io"
   resources:
   - ingresses/status
   verbs:

docs-web/configuration/ingress-resources/advanced-configuration-with-annotations.md

@@ -12,7 +12,7 @@ Customization and fine-tuning is also available through the [ConfigMap](/nginx-i
 
 Here is an example of using annotations to customize the configuration for a particular Ingress resource:
 ```yaml
-apiVersion: extensions/v1beta1
+apiVersion: networking.k8s.io/v1beta1
 kind: Ingress
 metadata:
   name: cafe-ingress-with-annotations

docs-web/configuration/ingress-resources/advanced-configuration-with-snippets.md

@@ -8,7 +8,7 @@ Snippets are also available through the [ConfigMap](/nginx-ingress-controller/co
 
 The example below shows how to use snippets to customize the NGINX configuration template using annotations.
 ```yaml
-apiVersion: extensions/v1beta1
+apiVersion: networking.k8s.io/v1beta1
 kind: Ingress
 metadata:
   name: cafe-ingress-with-snippets

docs-web/configuration/ingress-resources/basic-configuration.md

@@ -2,7 +2,7 @@
 
 The example below shows a basic Ingress resource definition. It load balances requests for two services -- coffee and tea -- comprising a hypothetical *cafe* app hosted at `cafe.example.com`:
 ```yaml
-apiVersion: extensions/v1beta1
+apiVersion: networking.k8s.io/v1beta1
 kind: Ingress
 metadata:
   name: cafe-ingress
@@ -15,7 +15,7 @@ spec:
   - host: cafe.example.com
     http:
       paths:
-      - path: /tea
+      - path: "/tea"
         backend:
           serviceName: tea-svc
           servicePort: 80
@@ -32,14 +32,38 @@ Here is a breakdown of what this Ingress resource definition means:
     * In the `hosts` field, we apply the certificate and key to our `cafe.example.com` host.
 * In the `spec.rules` field, we define a host with domain name `cafe.example.com`.
 * In the `paths` field, we define two path‑based rules:
-  * The rule with the path `/tea` instructs NGINX to distribute the requests with the `/tea` URI among the pods of the *tea* service, which is deployed with the name `tea‑svc` in the cluster.
+  * The rule with the path `/tea` instructs NGINX to distribute the requests with the  `/tea` URI among the pods of the *tea* service, which is deployed with the name `tea‑svc` in the cluster.
   * The rule with the path `/coffee` instructs NGINX to distribute the requests with the `/coffee` URI among the pods of the *coffee* service, which is deployed with the name `coffee‑svc` in the cluster.
   * Both rules instruct NGINX to distribute the requests to `port 80` of the corresponding service (the `servicePort` field).
 
 > For complete instructions on deploying the Ingress and Secret resources in the cluster, see the [complete-example](https://github.com/nginxinc/kubernetes-ingress/tree/master/examples/complete-example) in our GitHub repo.
 
 > To learn more about the Ingress resource, see the [Ingress resource documentation](https://kubernetes.io/docs/concepts/services-networking/ingress/) in the Kubernetes docs.
 
+## New Features Available in Kubernetes 1.18 and Above
+
+Starting from Kubernetes 1.18, you can use the following new features:
+
+* The host field supports wildcard domain names, such as *.example.com.
+* The path supports different matching rules with the new field PathType, which takes the following values: Prefix for prefix-based matching, Exact for exact matching and ImplementationSpecific, which is the default type and is the same as Prefix. For example:
+```yaml
+   - path: /tea
+      pathType: Prefix
+      backend:
+        serviceName: tea-svc
+        servicePort: 80
+    - path: /tea/green
+      pathType: Exact
+      backend:
+        serviceName: tea-svc
+        servicePort: 80
+   - path: /coffee
+      pathType: ImplementationSpecific # default
+      backend:
+        serviceName: coffee-svc
+        servicePort: 80
+```
+
 ## Restrictions
 
 The NGINX Ingress Controller imposes the following restrictions on Ingress resources:

docs-web/configuration/ingress-resources/custom-annotations.md

@@ -33,7 +33,7 @@ Consider the following excerpt from the template, which was extended to support
 
 Consider the following Ingress resource and note how we set two annotations:
 ```yaml
-apiVersion: extensions/v1beta1
+apiVersion: networking.k8s.io/v1beta1
 kind: Ingress
 metadata:
   name: example-ingress

examples/appprotect/cafe-ingress.yaml

@@ -1,4 +1,4 @@
-apiVersion: extensions/v1beta1
+apiVersion: networking.k8s.io/v1beta1
 kind: Ingress
 metadata:
   name: cafe-ingress

examples/complete-example/cafe-ingress.yaml

@@ -1,4 +1,4 @@
-apiVersion: extensions/v1beta1
+apiVersion: networking.k8s.io/v1beta1
 kind: Ingress
 metadata:
   name: cafe-ingress

examples/custom-annotations/README.md

@@ -81,7 +81,7 @@ Customize the template for Ingress resources to include the logic to handle and
 
 1. Create a file with the following Ingress resource (`cafe-ingress.yaml`) and use the custom annotations to enable rate-limiting:
     ```yaml
-    apiVersion: extensions/v1beta1
+    apiVersion: networking.k8s.io/v1beta1
     kind: Ingress
     metadata:
       name: cafe-ingress

examples/externalname-services/README.md

@@ -40,7 +40,7 @@ spec:
 In the following Ingress resource we use my-service:
 
 ```yaml
-apiVersion: extensions/v1beta1
+apiVersion: networking.k8s.io/v1beta1
 kind: Ingress
 metadata:
   name: example-ingress

examples/grpc-services/README.md

@@ -18,7 +18,7 @@ nginx.org/grpc-services: "service1[,service2,...]"
 
 In the following example we load balance three applications, one of which is using gRPC:
 ```yaml
-apiVersion: extensions/v1beta1
+apiVersion: networking.k8s.io/v1beta1
 kind: Ingress
 metadata:
   name: grpc-ingress

examples/health-checks/README.md

@@ -15,7 +15,7 @@ The Ingress controller provides the following annotations for configuring active
 
 In the following example we enable active health checks in the cafe-ingress Ingress:
 ```yaml
-apiVersion: extensions/v1beta1
+apiVersion: networking.k8s.io/v1beta1
 kind: Ingress
 metadata:
   name: cafe-ingress

examples/jwt/README.md

@@ -13,7 +13,7 @@ The Ingress controller provides the following 4 annotations for configuring JWT
 
 In the following example we enable JWT validation for the cafe-ingress Ingress for all paths using the same key `cafe-jwk`:
 ```yaml
-apiVersion: extensions/v1beta1
+apiVersion: networking.k8s.io/v1beta1
 kind: Ingress
 metadata:
   name: cafe-ingress
@@ -51,7 +51,7 @@ In the following example we enable JWT validation for the [mergeable Ingresses](
 
 * Master:
   ```yaml
-  apiVersion: extensions/v1beta1
+  apiVersion: networking.k8s.io/v1beta1
   kind: Ingress
   metadata:
     name: cafe-ingress-master
@@ -69,7 +69,7 @@ In the following example we enable JWT validation for the [mergeable Ingresses](
 
 * Tea minion:
   ```yaml
-  apiVersion: extensions/v1beta1
+  apiVersion: networking.k8s.io/v1beta1
   kind: Ingress
   metadata:
     name: cafe-ingress-tea-minion
@@ -93,7 +93,7 @@ In the following example we enable JWT validation for the [mergeable Ingresses](
 
 * Coffee minion:
   ```yaml
-  apiVersion: extensions/v1beta1
+  apiVersion: networking.k8s.io/v1beta1
   kind: Ingress
   metadata:
     name: cafe-ingress-coffee-minion

examples/mergeable-ingress-types/cafe-master.yaml

@@ -1,4 +1,4 @@
-apiVersion: extensions/v1beta1
+apiVersion: networking.k8s.io/v1beta1
 kind: Ingress
 metadata:
   name: cafe-ingress-master

examples/mergeable-ingress-types/coffee-minion.yaml

@@ -1,4 +1,4 @@
-apiVersion: extensions/v1beta1
+apiVersion: networking.k8s.io/v1beta1
 kind: Ingress
 metadata:
   name: cafe-ingress-coffee-minion

examples/mergeable-ingress-types/tea-minion.yaml

@@ -1,4 +1,4 @@
-apiVersion: extensions/v1beta1
+apiVersion: networking.k8s.io/v1beta1
 kind: Ingress
 metadata:
   name: cafe-ingress-tea-minion

examples/rewrites/README.md

@@ -13,7 +13,7 @@ nginx.org/rewrites: "serviceName=service1 rewrite=rewrite1[;serviceName=service2
 
 In the following example we load balance two applications that require URI rewriting:
 ```yaml
-apiVersion: extensions/v1beta1
+apiVersion: networking.k8s.io/v1beta1
 kind: Ingress
 metadata:
   name: cafe-ingress

examples/session-persistence/README.md

@@ -20,7 +20,7 @@ The syntax of the *cookieName*, *expires*, *domain*, *httponly*, *secure* and *p
 
 In the following example we enable session persistence for two services -- the *tea-svc* service and the *coffee-svc* service:
 ```yaml
-apiVersion: extensions/v1beta1
+apiVersion: networking.k8s.io/v1beta1
 kind: Ingress
 metadata:
   name: cafe-ingress-with-session-persistence

examples/session-persistence/cafe-ingress-with-session-persistence.yaml

@@ -1,4 +1,4 @@
-apiVersion: extensions/v1beta1
+apiVersion: networking.k8s.io/v1beta1
 kind: Ingress
 metadata:
   name: cafe-ingress-with-session-persistence

examples/ssl-services/README.md

@@ -8,7 +8,7 @@ nginx.org/ssl-services: "service1[,service2,...]"
 
 In the following example we load balance three applications, one of which requires HTTPS:
 ```yaml
-apiVersion: extensions/v1beta1
+apiVersion: networking.k8s.io/v1beta1
 kind: Ingress
 metadata:
   name: cafe-ingress

examples/websocket/README.md

@@ -7,7 +7,7 @@ nginx.org/websocket-services: "service1[,service2,...]"
 
 In the following example we load balance three applications, one of which is using WebSocket:
 ```yaml
-apiVersion: extensions/v1beta1
+apiVersion: networking.k8s.io/v1beta1
 kind: Ingress
 metadata:
   name: cafe-ingress

examples/wildcard-tls-certificate/README.md

@@ -21,7 +21,7 @@ In the example below we configure TLS termination for two Ingress resources for
 `foo-ingress` from the namespace `foo-namespace`:
 
  ```yaml
-apiVersion: extensions/v1beta1
+apiVersion: networking.k8s.io/v1beta1
 kind: Ingress
 metadata:
   name: foo-ingress
@@ -45,7 +45,7 @@ spec:
 `bar-ingress` from the namespace `bar-namespace`:
 
 ```yaml
-apiVersion: extensions/v1beta1
+apiVersion: networking.k8s.io/v1beta1
 kind: Ingress
 metadata:
   name: bar-ingress

internal/configs/configurator.go

@@ -18,7 +18,7 @@ import (
 
 	"github.com/golang/glog"
 	api_v1 "k8s.io/api/core/v1"
-	extensions "k8s.io/api/extensions/v1beta1"
+	networking "k8s.io/api/networking/v1beta1"
 	meta_v1 "k8s.io/apimachinery/pkg/apis/meta/v1"
 
 	"github.com/nginxinc/kubernetes-ingress/internal/configs/version1"
@@ -879,14 +879,14 @@ func getFileNameForTransportServerFromKey(key string) string {
 }
 
 // HasIngress checks if the Ingress resource is present in NGINX configuration.
-func (cnf *Configurator) HasIngress(ing *extensions.Ingress) bool {
+func (cnf *Configurator) HasIngress(ing *networking.Ingress) bool {
 	name := objectMetaToFileName(&ing.ObjectMeta)
 	_, exists := cnf.ingresses[name]
 	return exists
 }
 
 // HasMinion checks if the minion Ingress resource of the master is present in NGINX configuration.
-func (cnf *Configurator) HasMinion(master *extensions.Ingress, minion *extensions.Ingress) bool {
+func (cnf *Configurator) HasMinion(master *networking.Ingress, minion *networking.Ingress) bool {
 	masterName := objectMetaToFileName(&master.ObjectMeta)
 
 	if _, exists := cnf.minions[masterName]; !exists {
@@ -990,7 +990,7 @@ func (cnf *Configurator) updateApResources(ingEx *IngressEx) map[string]string {
 		policyContent := generateApResourceFileContent(ingEx.AppProtectPolicy)
 		cnf.nginxManager.CreateAppProtectResourceFile(policyFileName, policyContent)
 		apRes[appProtectPolicyKey] = policyFileName
-	
+
 	}
 
 	if ingEx.AppProtectLogConf != nil {