docs: update all ingress objects to networking.k8s.io/v1

docs/best-practices.md

@@ -19,7 +19,7 @@ to the ingress rules so that it is possible to specifically reach to the desired
 pods or stable pods.
 
 ```yaml
-apiVersion: networking.k8s.io/v1beta1
+apiVersion: networking.k8s.io/v1
 kind: Ingress
 metadata:
   name: guestbook
@@ -29,25 +29,36 @@ spec:
   - host: guestbook-desired.argoproj.io
     http:
       paths:
-      - backend:
-          serviceName: guestbook-desired
-          servicePort: 443
-        path: /*
+      - path: /
+        pathType: Prefix
+        backend:
+          service:
+            name: guestbook-desired
+            port:
+              number: 443
+
   # host rule to only reach the stable pods
   - host: guestbook-stable.argoproj.io
     http:
       paths:
-      - backend:
-          serviceName: guestbook-stable
-          servicePort: 443
-        path: /*
+      - path: /
+        pathType: Prefix
+        backend:
+          service:
+            name: guestbook-stable
+            port:
+              number: 443
+
   # default rule which omits host, and will split traffic between desired vs. stable
   - http:
       paths:
-      - backend:
-          serviceName: guestbook-root
-          servicePort: 443
-        path: /*
+      - path: /
+        pathType: Prefix
+        backend:
+          service:
+            name: guestbook-root
+            port:
+            number: 443
 ```
 
 The above technique has the a benefit in that it would not incur additional cost of allocating

docs/features/traffic-management/alb.md

@@ -53,7 +53,7 @@ spec:
           ingress: ingress
           # If you want to controll multiple ingress resources you can use the ingresses field, if ingresses is specified
           # the ingress field will need to be omitted.
-          ingresses: 
+          ingresses:
            - ingress-1
            - ingress-2
           # Reference to a Service that the Ingress must target in one of the rules (optional).
@@ -66,7 +66,7 @@ spec:
 The referenced Ingress should be deployed with an ingress rule that matches the Rollout service:
 
 ```yaml
-apiVersion: networking.k8s.io/v1beta1
+apiVersion: networking.k8s.io/v1
 kind: Ingress
 metadata:
   name: ingress
@@ -76,14 +76,17 @@ spec:
   rules:
   - http:
       paths:
-      - path: /*
+      - path: /
+        pathType: Prefix
         backend:
-          # serviceName must match either: canary.trafficRouting.alb.rootService (if specified),
-          # or canary.stableService (if rootService is omitted)
-          serviceName: root-service
-          # servicePort must be the value: use-annotation
-          # This instructs AWS Load Balancer Controller to look to annotations on how to direct traffic
-          servicePort: use-annotation
+          service:
+            # serviceName must match either: canary.trafficRouting.alb.rootService (if specified),
+            # or canary.stableService (if rootService is omitted)
+            name: root-service
+            # servicePort must be the value: use-annotation
+            # This instructs AWS Load Balancer Controller to look to annotations on how to direct traffic
+            port:
+              name: use-annotation
 ```
 
 During an update, the rollout controller injects the `alb.ingress.kubernetes.io/actions.<SERVICE-NAME>`
@@ -95,7 +98,7 @@ annotation that splits traffic between the canary-service and stable-service, wi
 of 10 and 90 respectively:
 
 ```yaml
-apiVersion: networking.k8s.io/v1beta1
+apiVersion: networking.k8s.io/v1
 kind: Ingress
 metadata:
   name: ingress
@@ -123,10 +126,13 @@ spec:
   rules:
   - http:
       paths:
-      - path: /*
+      - path: /
+        pathType: Prefix
         backend:
-          serviceName: root-service
-          servicePort: use-annotation
+          service:
+            name: root-service
+            port:
+              name: use-annotation
 ```
 
 !!! note
@@ -411,7 +417,7 @@ spec:
 By default, Argo Rollout will operate on Ingresses with the annotation:
 
 ```yaml
-apiVersion: networking.k8s.io/v1beta1
+apiVersion: networking.k8s.io/v1
 kind: Ingress
 metadata:
   annotations:
@@ -420,7 +426,7 @@ metadata:
 
 Or with the `ingressClassName`:
 ```yaml
-apiVersion: networking.k8s.io/v1beta1
+apiVersion: networking.k8s.io/v1
 kind: Ingress
 spec:
   ingressClassName: alb

docs/getting-started/alb/index.md

@@ -1,7 +1,7 @@
 # Getting Started - AWS Load Balancer Controller
 
 This guide covers how Argo Rollouts integrates with the
-[AWS Load Balancer Controller](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/) 
+[AWS Load Balancer Controller](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/)
 for traffic shaping. This guide builds upon the concepts of the [basic getting started guide](../../getting-started.md).
 
 ## Requirements
@@ -48,7 +48,7 @@ This should be `canary.trafficRouting.alb.rootService` (if specified), otherwise
 use `canary.stableService`.
 
 ```yaml
-apiVersion: networking.k8s.io/v1beta1
+apiVersion: networking.k8s.io/v1
 kind: Ingress
 metadata:
   name: rollouts-demo-ingress
@@ -58,20 +58,23 @@ spec:
   rules:
   - http:
       paths:
-      - path: /*
+      - path: /
+        pathType: Prefix
         backend:
-          # serviceName must match either: canary.trafficRouting.alb.rootService (if specified),
-          # or canary.stableService (if rootService is omitted)
-          serviceName: rollouts-demo-root
-          # servicePort must be the value: use-annotation
-          # This instructs AWS Load Balancer Controller to look to annotations on how to direct traffic
-          servicePort: use-annotation
+          service:
+            # serviceName must match either: canary.trafficRouting.alb.rootService (if specified),
+            # or canary.stableService (if rootService is omitted)
+            name: rollouts-demo-root
+            # servicePort must be the value: use-annotation
+            # This instructs AWS Load Balancer Controller to look to annotations on how to direct traffic
+            port:
+              name: use-annotation
 ```
 
 During an update, the Ingress will be injected with a
 [custom action annotation](https://kubernetes-sigs.github.io/aws-load-balancer-controller/latest/guide/ingress/annotations/#actions),
 which directs the ALB to splits traffic between the stable and canary Services referenced by the Rollout.
-In this example, those Services are named: `rollouts-demo-stable` and `rollouts-demo-canary` 
+In this example, those Services are named: `rollouts-demo-stable` and `rollouts-demo-canary`
 respectively.
 
 Run the following commands to deploy:
@@ -123,15 +126,15 @@ kubectl argo rollouts get rollout rollouts-demo
 ![Rollout ALB Paused](paused-rollout-alb.png)
 
 At this point, both the canary and stable version of the Rollout are running, with 5% of the
-traffic directed to the canary. To understand how this works, inspect the listener rules for 
-the ALB. When looking at the listener rules, we see that the forward action weights 
+traffic directed to the canary. To understand how this works, inspect the listener rules for
+the ALB. When looking at the listener rules, we see that the forward action weights
 have been modified by the controller to reflect the current weight of the canary.
 
 ![ALB Listener_Rules](alb-listener-rules.png)
 
-The controller has added `rollouts-pod-template-hash` selector to the Services and 
-attached the same label to the Pods. Therefore, you can split the traffic by simply 
+The controller has added `rollouts-pod-template-hash` selector to the Services and
+attached the same label to the Pods. Therefore, you can split the traffic by simply
 forwarding the requests to the Services according to the weights.
- 
+
 As the Rollout progresses through steps, the forward action weights will be adjusted to
 match the current setWeight of the steps.

docs/getting-started/alb/ingress.yaml

@@ -1,4 +1,4 @@
-apiVersion: networking.k8s.io/v1beta1
+apiVersion: networking.k8s.io/v1
 kind: Ingress
 metadata:
   name: rollouts-demo-ingress
@@ -8,7 +8,10 @@ spec:
   rules:
   - http:
       paths:
-      - path: /*
+      - path: /
+        pathType: Prefix
         backend:
-          serviceName: rollouts-demo-root
-          servicePort: use-annotation
+          service:
+            name: rollouts-demo-root
+            port:
+              name: use-annotation

docs/getting-started/mixed/index.md

@@ -4,11 +4,11 @@
     Available since v1.2
 
 This guide covers how Argo Rollouts integrates with multiple TrafficRoutings, using
-[Linkerd](https://linkerd.io) and 
+[Linkerd](https://linkerd.io) and
 [NGINX Ingress Controller](https://github.com/kubernetes/ingress-nginx) for traffic shaping, but you
 should be able to produce any other combination between the existing trafficRouting options.
 
-This guide builds upon the concepts of the [basic getting started guide](../../getting-started.md), 
+This guide builds upon the concepts of the [basic getting started guide](../../getting-started.md),
 [NGINX Guide](getting-started/nginx/index.md), and [SMI Guide](getting-started/smi/index.md).
 
 ## Requirements
@@ -89,7 +89,7 @@ rule which has a backend targeting the Service referenced under `canary.stableSe
 In our example, that stable Service is named: `rollouts-demo-stable`:
 
 ```yaml
-apiVersion: networking.k8s.io/v1beta1
+apiVersion: networking.k8s.io/v1
 kind: Ingress
 metadata:
   name: rollouts-demo-stable
@@ -101,10 +101,13 @@ spec:
     http:
       paths:
       - path: /
+        pathType: Prefix
         backend:
-          # Reference to a Service name, also specified in the Rollout spec.strategy.canary.stableService field
-          serviceName: rollouts-demo-stable
-          servicePort: 80
+          service:
+            # Reference to a Service name, also specified in the Rollout spec.strategy.canary.stableService field
+            name: rollouts-demo-stable
+            port:
+              number: 80
 ```
 
 Run the following commands to deploy:
@@ -183,8 +186,8 @@ kubectl argo rollouts get rollout rollouts-demo
 ![Rollout Paused](../nginx/paused-rollout-nginx.png)
 
 At this point, both the canary and stable version of the Rollout are running, with 5% of the
-traffic directed to the canary and 95% to the stable. When inspecting the TrafficSplit generated by 
-the controller, we see that the weight has been updated to reflect the current `setWeight: 5` step of 
+traffic directed to the canary and 95% to the stable. When inspecting the TrafficSplit generated by
+the controller, we see that the weight has been updated to reflect the current `setWeight: 5` step of
 the canary deploy.
 
 ```yaml

docs/getting-started/mixed/ingress.yaml

@@ -1,4 +1,4 @@
-apiVersion: networking.k8s.io/v1beta1
+apiVersion: networking.k8s.io/v1
 kind: Ingress
 metadata:
   name: rollouts-demo-stable
@@ -10,7 +10,10 @@ spec:
     http:
       paths:
       - path: /
+        pathType: Prefix
         backend:
-          # Reference to a Service name, also specified in the Rollout spec.strategy.canary.stableService field
-          serviceName: rollouts-demo-stable
-          servicePort: 80
+          service:
+            # Reference to a Service name, also specified in the Rollout spec.strategy.canary.stableService field
+            name: rollouts-demo-stable
+            port:
+              number: 80

docs/getting-started/nginx/index.md

@@ -1,7 +1,7 @@
 # Getting Started - NGINX Ingress
 
 This guide covers how Argo Rollouts integrates with the
-[NGINX Ingress Controller](https://github.com/kubernetes/ingress-nginx) for traffic shaping. 
+[NGINX Ingress Controller](https://github.com/kubernetes/ingress-nginx) for traffic shaping.
 This guide builds upon the concepts of the [basic getting started guide](../../getting-started.md).
 
 ## Requirements
@@ -41,7 +41,7 @@ rule which has a backend targeting the Service referenced under `canary.stableSe
 In our example, that stable Service is named: `rollouts-demo-stable`:
 
 ```yaml
-apiVersion: networking.k8s.io/v1beta1
+apiVersion: networking.k8s.io/v1
 kind: Ingress
 metadata:
   name: rollouts-demo-stable
@@ -53,10 +53,13 @@ spec:
     http:
       paths:
       - path: /
+        pathType: Prefix
         backend:
-          # Reference to a Service name, also specified in the Rollout spec.strategy.canary.stableService field
-          serviceName: rollouts-demo-stable
-          servicePort: 80
+          service:
+            # Reference to a Service name, also specified in the Rollout spec.strategy.canary.stableService field
+            name: rollouts-demo-stable
+            port:
+              number: 80
 ```
 
 Run the following commands to deploy:

docs/getting-started/nginx/ingress.yaml

@@ -1,4 +1,4 @@
-apiVersion: networking.k8s.io/v1beta1
+apiVersion: networking.k8s.io/v1
 kind: Ingress
 metadata:
   name: rollouts-demo-stable
@@ -10,7 +10,10 @@ spec:
     http:
       paths:
       - path: /
+        pathType: Prefix
         backend:
-          # Reference to a Service name, also specified in the Rollout spec.strategy.canary.stableService field
-          serviceName: rollouts-demo-stable
-          servicePort: 80
+          service:
+            # Reference to a Service name, also specified in the Rollout spec.strategy.canary.stableService field
+            name: rollouts-demo-stable
+            port:
+              number: 80

docs/getting-started/smi/ingress.yaml

@@ -1,4 +1,4 @@
-apiVersion: networking.k8s.io/v1beta1
+apiVersion: networking.k8s.io/v1
 kind: Ingress
 metadata:
   name: rollouts-demo-stable
@@ -16,7 +16,10 @@ spec:
     http:
       paths:
       - path: /
+        pathType: Prefix
         backend:
-          # Reference to a Service name, also specified in the Rollout spec.strategy.canary.stableService field
-          serviceName: rollouts-demo-stable
-          servicePort: 80
+          service:
+            # Reference to a Service name, also specified in the Rollout spec.strategy.canary.stableService field
+            name: rollouts-demo-stable
+            port:
+              number: 80