update: YAML file explanations: Networking labs (#1586)

Co-authored-by: Raj Athavale <[email protected]>

Author: athavr

manifests/modules/networking/network-policies/apply-network-policies/example-network-policy.yaml

@@ -0,0 +1,34 @@
+apiVersion: networking.k8s.io/v1
+kind: NetworkPolicy
+metadata:
+  name: test-network-policy
+  namespace: default
+spec:
+  podSelector:
+    matchLabels:
+      role: db
+  policyTypes:
+    - Ingress
+    - Egress
+  ingress:
+    - from:
+        - ipBlock:
+            cidr: 172.17.0.0/16
+            except:
+              - 172.17.1.0/24
+        - namespaceSelector:
+            matchLabels:
+              project: myproject
+        - podSelector:
+            matchLabels:
+              role: frontend
+      ports:
+        - protocol: TCP
+          port: 6379
+  egress:
+    - to:
+        - ipBlock:
+            cidr: 10.0.0.0/24
+      ports:
+        - protocol: TCP
+          port: 5978

website/docs/networking/eks-hybrid-nodes/connect-hybrid-node.md

@@ -22,12 +22,13 @@ $ export ACTIVATION_ID=$(echo $ACTIVATION_JSON | jq -r ".ActivationId")
 $ export ACTIVATION_CODE=$(echo $ACTIVATION_JSON | jq -r ".ActivationCode")
 ```
 
-With our activation created, we can now create a `nodeconfig.yaml` which will be
-referenced when we join our instance to the cluster. This utilizes the SSM
-`ACTIVATION_CODE` and `ACTIVATION_ID` created in the previous step as well as
-the `EKS_CLUSTER_NAME` name and `AWS_REGION` environment variables.
+With our activation created, we can now create a `NodeConfig` which will be
+referenced when we join our instance to the cluster. 
 
-::yaml{file="manifests/modules/networking/eks-hybrid-nodes/nodeconfig.yaml"}
+::yaml{file="manifests/modules/networking/eks-hybrid-nodes/nodeconfig.yaml" paths="spec.cluster,spec.hybrid.ssm"}
+
+1. Specify the target EKS cluster `name` and `region` using the  `$EKS_CLUSTER_NAME` and `$AWS_REGION` environment variables
+2. Specify the SSM `activationCode` and `activationId` by using the `$ACTIVATION_CODE` and `$ACTIVATION_ID` environment variables created in the previous step 
 
 ```bash
 $ cat ~/environment/eks-workshop/modules/networking/eks-hybrid-nodes/nodeconfig.yaml \
@@ -73,7 +74,20 @@ Great! The node appears but with a `NotReady` status. This is because we must in
 $ helm repo add cilium https://helm.cilium.io/
 ```
 
-With the repo added, we can install Cilium using the configuration provided below.
+Next, let us look at the configuration values we will provide as input to the Cilium helm chart:
+
+::yaml{file="manifests/modules/networking/eks-hybrid-nodes/cilium-values.yaml" paths="affinity.nodeAffinity,ipam.mode,ipam.operator.clusterPoolIPv4MaskSize,ipam.operator.clusterPoolIPv4PodCIDRList,operator.replicas,operator.affinity,operator.unmanagedPodWatcher.restart,envoy.enabled"}
+
+1. This `affinity.nodeAffinity` configuration targets nodes by `eks.amazonaws.com/compute-type` and ensures that the main CNI daemonset pods that handle networking on each node only run on `hybrid` nodes
+2. Set `ipam.mode` to `cluster-pool` to use cluster-wide IP pool for pod IP allocation
+3. Set `clusterPoolIPv4MaskSize: 25` to specify `/25` subnets allocated per node (128 IP addresses)
+4. Set `clusterPoolIPv4PodCIDRList` to `10.53.0.0/16` to specify the dedicated CIDR for the hybrid node pods
+5. Set `replicas: 1` to specify a single instance of the operator will run
+6. This `affinity.nodeAffinity` configuration targets nodes by `eks.amazonaws.com/compute-type` and ensures that the main CNI operator pods that manage the CNI configuration on each node only run on `hybrid` nodes
+7. Set `unmanagedPodWatcher.restart: false` to disable pod restart watching
+8. Set `envoy.enabled: false` to disable Envoy proxy integration
+
+Let us install Cilium using this configuration.
 
 ```bash timeout=300 wait=30
 $ helm install cilium cilium/cilium \
@@ -83,8 +97,6 @@ $ helm install cilium cilium/cilium \
 --values ~/environment/eks-workshop/modules/networking/eks-hybrid-nodes/cilium-values.yaml
 ```
 
-::yaml{file="manifests/modules/networking/eks-hybrid-nodes/cilium-values.yaml"}
-
 After installing Cilium our Hybrid Node should come up, happy and healthy.
 
 ```bash timeout=300 wait=30

website/docs/networking/vpc-cni/network-policies/debug.md

@@ -7,11 +7,12 @@ Till now, we were able to apply network policies without issues or errors. But w
 
 Amazon VPC CNI provides logs that can be used to debug issues while implementing networking policies. In addition, you can monitor these logs through services such as Amazon CloudWatch, where you can leverage CloudWatch Container Insights that can help you provide insights on your usage related to NetworkPolicy.
 
-Now, let us try implementing an ingress network policy that will restrict access to the orders' service component from 'ui' component only, similar to what we did earlier with the 'catalog' service component..
+Now, let us try implementing an ingress network policy that will restrict access to the orders' service component from 'ui' component only, similar to what we did earlier with the 'catalog' service component.
 
-```file
-manifests/modules/networking/network-policies/apply-network-policies/allow-order-ingress-fail-debug.yaml
-```
+::yaml{file="manifests/modules/networking/network-policies/apply-network-policies/allow-order-ingress-fail-debug.yaml" paths="spec.podSelector,spec.ingress.0.from.0"}
+
+1. The `podSelector` targets pods with labels `app.kubernetes.io/name: orders` and `app.kubernetes.io/component: service`
+2. The `ingress.from` allows inbound connections only from pods with the label `app.kubernetes.io/name: ui`
 
 Lets apply this policy:
 

website/docs/networking/vpc-cni/network-policies/egress.md

@@ -7,9 +7,10 @@ sidebar_position: 70
 
 As shown in the above architecture diagram, the 'ui' component is the front-facing app. So we can start implementing our network controls for the 'ui' component by defining a network policy that will block all egress traffic from the 'ui' namespace.
 
-```file
-manifests/modules/networking/network-policies/apply-network-policies/default-deny.yaml
-```
+::yaml{file="manifests/modules/networking/network-policies/apply-network-policies/default-deny.yaml" paths="spec.podSelector,spec.policyTypes"}
+
+1. The empty selector `{}` matches all pods
+2. The `Egress` policy type controls outbound traffic from pods
 
 > **Note** : There is no namespace specified in the network policy, as it is a generic policy that can potentially be applied to any namespace in our cluster.
 
@@ -38,14 +39,12 @@ Implementing the above policy will also cause the sample application to no longe
 
 In the case of the 'ui' component, it needs to communicate with all the other service components, such as 'catalog', 'orders, etc. Apart from this, 'ui' will also need to be able to communicate with components in the cluster system namespaces. For example, for the 'ui' component to work, it needs to be able to perform DNS lookups, which requires it to communicate with the CoreDNS service in the `kube-system` namespace.
 
-The network policy below was designed with the above requirements in mind. It has two key sections:
+The network policy below was designed with the above requirements in mind.
 
-- The first section focuses on allowing egress traffic to all service components such as 'catalog', 'orders' etc. without providing access to the database components through a combination of namespaceSelector, which allows for egress traffic to any namespace as long as the pod labels match "app.kubernetes.io/component: service".
-- The second section focuses on allowing egress traffic to all components in the kube-system namespace, which enables DNS lookups and other key communications with the components in the system namespace.
+::yaml{file="manifests/modules/networking/network-policies/apply-network-policies/allow-ui-egress.yaml" paths="spec.egress.0.to.0,spec.egress.0.to.1"}
 
-```file
-manifests/modules/networking/network-policies/apply-network-policies/allow-ui-egress.yaml
-```
+1. The first egress rule focuses on allowing egress traffic to all `service` components such as 'catalog', 'orders' etc. (without providing access to the database components), along with the `namespaceSelector` which allows for egress traffic to any namespace as long as the pod labels match `app.kubernetes.io/component: service`
+2. The second egress rule focuses on allowing egress traffic to all components in the `kube-system` namespace, which enables DNS lookups and other key communications with the components in the system namespace
 
 Lets apply this additional policy:
 

website/docs/networking/vpc-cni/network-policies/index.md

@@ -18,51 +18,15 @@ $ prepare-environment networking/network-policies
 
 By default, Kubernetes allows all pods to freely communicate with each other with no restrictions. Kubernetes Network Policies enable you to define and enforce rules on the flow of traffic between pods, namespaces, and IP blocks (CIDR ranges). They act as a virtual firewall, allowing you to segment and secure your cluster by specifying ingress (incoming) and egress (outgoing) network traffic rules based on various criteria such as pod labels, namespaces, IP addresses, and ports.
 
-Below is an example of a network policy,
+Below is an example network policy with an explanation of some key elements:
 
-```yaml
-apiVersion: networking.k8s.io/v1
-kind: NetworkPolicy
-metadata:
-  name: test-network-policy
-  namespace: default
-spec:
-  podSelector:
-    matchLabels:
-      role: db
-  policyTypes:
-    - Ingress
-    - Egress
-  ingress:
-    - from:
-        - ipBlock:
-            cidr: 172.17.0.0/16
-            except:
-              - 172.17.1.0/24
-        - namespaceSelector:
-            matchLabels:
-              project: myproject
-        - podSelector:
-            matchLabels:
-              role: frontend
-      ports:
-        - protocol: TCP
-          port: 6379
-  egress:
-    - to:
-        - ipBlock:
-            cidr: 10.0.0.0/24
-      ports:
-        - protocol: TCP
-          port: 5978
-```
-
-The network policy specification contains the following key segments:
+::yaml{file="manifests/modules/networking/network-policies/apply-network-policies/example-network-policy.yaml" paths="metadata,spec.podSelector,spec.policyTypes,spec.ingress,spec.egress" title="example-network-policy.yaml"}
 
-- **metadata**: similar to other Kubernetes objects, it allows you to specify the name and namespace for the given network policy.
-- **spec.podSelector**: allows for the selection of specific pods based on their labels within the namespace to which the given network policy will be applied. If an empty pod selector or matchLabels is specified in the specification, then the policy will be applied to all the pods within the namespace.
-- **spec.policyTypes**: specifies whether the policy will be applied to ingress traffic, egress traffic, or both for the selected pods. If you do not specify this field, then the default behavior is to apply the network policy to ingress traffic only, unless the network policy has an egress section, in which case the network policy will be applied to both ingress and egress traffic.
-- **ingress**: allows for ingress rules to be configured that specify from which pods (podSelector), namespace (namespaceSelector), or CIDR range (ipBlock) traffic is allowed to the selected pods and which port or port range can be used. If a port or port range is not specified, any port can be used for communication.
+1. Similar to other Kubernetes objects, `metadata` allows you to specify the name and namespace for the given network policy
+2. `spec.podSelector` allows for the selection of specific pods based on their labels within the namespace to which the given network policy will be applied. If an empty pod selector or matchLabels is specified in the specification, then the policy will be applied to all the pods within the namespace.
+3. `spec.policyTypes` specifies whether the policy will be applied to ingress traffic, egress traffic, or both for the selected pods. If you do not specify this field, then the default behavior is to apply the network policy to ingress traffic only, unless the network policy has an egress section, in which case the network policy will be applied to both ingress and egress traffic.
+4. `ingress` allows for ingress rules to be configured that specify from which pods (`podSelector`), namespace (`namespaceSelector`), or CIDR range (`ipBlock`) traffic is allowed to the selected pods and which port or port range can be used. If a port or port range is not specified, any port can be used for communication.
+5. `egress` allows for egress rules to be configured that specify to which pods (`podSelector`), namespace (`namespaceSelector`), or CIDR range (`ipBlock`) traffic is allowed from the selected pods and which port or port range can be used. If a port or port range is not specified, any port can be used for communication.
 
 For more information about what capabilities are allowed or restricted for Kubernetes network policies, refer to the [Kubernetes docs](https://kubernetes.io/docs/concepts/services-networking/network-policies/).
 

website/docs/networking/vpc-cni/network-policies/ingress.md

@@ -41,9 +41,10 @@ $ kubectl exec deployment/orders -n orders -- curl -v catalog.catalog/health --c
 
 Now, we'll define a network policy that will allow traffic to the 'catalog' service component only from the 'ui' component:
 
-```file
-manifests/modules/networking/network-policies/apply-network-policies/allow-catalog-ingress-webservice.yaml
-```
+::yaml{file="manifests/modules/networking/network-policies/apply-network-policies/allow-catalog-ingress-webservice.yaml" paths="spec.podSelector,spec.ingress.0.from.0"}
+
+1. The `podSelector` targets pods with labels `app.kubernetes.io/name: catalog` and `app.kubernetes.io/component: service`
+2. This `ingress.from` configuration allows inbound connections only from pods running in the `ui` namespace identified by `kubernetes.io/metadata.name: ui` with label `app.kubernetes.io/name: ui` 
 
 Lets apply the policy:
 
@@ -82,9 +83,10 @@ As you could see from the above outputs, only the 'ui' component is able to comm
 
 But this still leaves the 'catalog' database component open, so let us implement a network policy to ensure only the 'catalog' service component alone can communicate with the 'catalog' database component.
 
-```file
-manifests/modules/networking/network-policies/apply-network-policies/allow-catalog-ingress-db.yaml
-```
+::yaml{file="manifests/modules/networking/network-policies/apply-network-policies/allow-catalog-ingress-db.yaml" paths="spec.podSelector,spec.ingress.0.from.0"}
+
+1. The `podSelector` targets pods with labels `app.kubernetes.io/name: catalog` and `app.kubernetes.io/component: mysql`
+2. The `ingress.from` allows inbound connections only from pods with labels `app.kubernetes.io/name: catalog` and `app.kubernetes.io/component: service`
 
 Lets apply the policy:
 

website/docs/networking/vpc-cni/prefix/consume.md

@@ -5,11 +5,12 @@ sidebar_position: 40
 
 To demonstrate VPC CNI behavior of adding additional prefixes to our worker nodes, we'll deploy pause pods to utilize more IP addresses than are currently assigned. We're utilizing a large number of these pods to simulate the addition of application pods in to the cluster either through deployments or scaling operations.
 
-```file
-manifests/modules/networking/prefix/deployment-pause.yaml
-```
+::yaml{file="manifests/modules/networking/prefix/deployment-pause.yaml" paths="spec.replicas,spec.template.spec.containers.0.image"}
+
+1. Creates 150 identical pods
+2. Set the image to `registry.k8s.io/pause` which provides a lightweight container that consumes minimal resources
 
-This will spin up `150 pods` and may take some time:
+Apply the pause pod deployment and wait for it to be ready. It may take some time to spin up the `150 pods`:
 
 ```bash
 $ kubectl apply -k ~/environment/eks-workshop/modules/networking/prefix

website/docs/networking/vpc-cni/security-groups-for-pods/add-sg.md

@@ -65,9 +65,10 @@ This security group:
 
 In order for our Pod to use this security group, we need to use the `SecurityGroupPolicy` CRD to tell EKS which security group is to be mapped to a specific set of Pods. This is what we'll configure:
 
-```file
-manifests/modules/networking/securitygroups-for-pods/sg/policy.yaml
-```
+::yaml{file="manifests/modules/networking/securitygroups-for-pods/sg/policy.yaml" paths="spec.podSelector,spec.securityGroups.groupIds"}
+
+1. The `podSelector` targets pods with label `app.kubernetes.io/component: service`
+2. The `CATALOG_SG_ID` environment variable we exported above contains the security group ID that will be mapped to the matching pods 
 
 Apply this to the cluster then recycle the catalog Pods once again:
 

website/docs/networking/vpc-lattice/configuring-routes.md

@@ -22,9 +22,19 @@ checkout-854cd7cd66-s2blp   1/1     Running   0          26s
 
 Now let's demonstrate how weighted routing works by creating `HTTPRoute` resources. First we'll create a `TargetGroupPolicy` that tells Lattice how to properly perform health checks on our checkout service:
 
-```file
-manifests/modules/networking/vpc-lattice/target-group-policy/target-group-policy.yaml
-```
+::yaml{file="manifests/modules/networking/vpc-lattice/target-group-policy/target-group-policy.yaml" paths="spec.targetRef,spec.healthCheck,spec.healthCheck.intervalSeconds,spec.healthCheck.timeoutSeconds,spec.healthCheck.healthyThresholdCount,spec.healthCheck.unhealthyThresholdCount,spec.healthCheck.path,spec.healthCheck.port,spec.healthCheck.protocol,spec.healthCheck.statusMatch"}
+
+1. `targetRef` applies this policy to the `checkout` Service  
+2. The settings in the `healthCheck` section defines how VPC Lattice monitors service health
+3. `intervalSeconds: 10` : Check every 10 seconds
+4. `timeoutSeconds: 1` : 1-second timeout per check
+5. `healthyThresholdCount: 3` : 3 consecutive successes = healthy
+6. `unhealthyThresholdCount: 2` : 2 consecutive failures = unhealthy
+7. `path: "/health"`: Health check endpoint path
+8. `port: 8080` : Health check endpoint port
+9. `protocol: HTTP` : Health check endpoint protocol
+10. `statusMatch: "200"` : Expects HTTP 200 response
+
 
 Apply this resource:
 
@@ -34,9 +44,11 @@ $ kubectl apply -k ~/environment/eks-workshop/modules/networking/vpc-lattice/tar
 
 Now create the Kubernetes `HTTPRoute` route that distributes 75% traffic to `checkoutv2` and remaining 25% traffic to `checkout`:
 
-```file
-manifests/modules/networking/vpc-lattice/routes/checkout-route.yaml
-```
+::yaml{file="manifests/modules/networking/vpc-lattice/routes/checkout-route.yaml" paths="spec.parentRefs.0,spec.rules.0.backendRefs.0,spec.rules.0.backendRefs.1"}
+
+1. `parentRefs` attaches this `HTTPRoute` route to the `http` listener on the gateway named `${EKS_CLUSTER_NAME}`
+2. This `backendRefs` rule sends `25%` of the traffic to the `checkout` Service in the `checkout` namespace on port `80`
+3. This `backendRefs` rule sends `75%` of the traffic to the `checkout` Service in the `checkoutv2` namespace on port `80`
 
 Apply this resource:
 

website/docs/networking/vpc-lattice/service-network.md

@@ -7,9 +7,10 @@ The Gateway API controller has been configured to create a VPC Lattice service n
 
 Before creating a `Gateway`, we need to formalize the types of load balancing implementations that are available via the Kubernetes resource model with a [GatewayClass](https://gateway-api.sigs.k8s.io/concepts/api-overview/#gatewayclass). The controller that listens to the Gateway API relies on an associated `GatewayClass` resource that the user can reference from their `Gateway`:
 
-```file
-manifests/modules/networking/vpc-lattice/controller/gatewayclass.yaml
-```
+::yaml{file="manifests/modules/networking/vpc-lattice/controller/gatewayclass.yaml" paths="metadata.name,spec.controllerName"}
+
+1. Set `amazon-vpc-lattice` as the `GatewayClass` name for reference by `Gateway` resources
+2. Set `application-networking.k8s.aws/gateway-api-controller` as the `controllerName` to specify the AWS Gateway API controller that manages gateways of this class
 
 Lets create the `GatewayClass`:
 
@@ -19,9 +20,11 @@ $ kubectl apply -f ~/environment/eks-workshop/modules/networking/vpc-lattice/con
 
 The following YAML will create a Kubernetes `Gateway` resource which is associated with a VPC Lattice **Service Network**.
 
-```file
-manifests/modules/networking/vpc-lattice/controller/eks-workshop-gw.yaml
-```
+::yaml{file="manifests/modules/networking/vpc-lattice/controller/eks-workshop-gw.yaml" paths="metadata.name,spec.gatewayClassName,spec.listeners.0"}
+
+1. Set the Gateway identifier as the EKS Cluster name by setting `metadata.name` to the `EKS_CLUSTER_NAME` environment variable
+2. Set `amazon-vpc-lattice` as the `gatewayClassName` to refer to the VPC Lattice GatewayClass defined earlier
+3. This configuration specifies that the `listener` will accept `HTTP` traffic on port `80`
 
 Apply it with the following command: