Rules and Traffic Considerations with CLAS
In Container Local Actor Store (CLAS) deployments, be sure to take into account the following special traffic and policy rules considerations that differ from legacy non-CLAS environments that are described in other sections of this chapter.
Mandatory Rules
The CLAS architecture requires mandatory infrastructure rules to be in place for the cluster to work properly. Do not upgrade to the CLAS mode, or move the cluster to Full Enforcement until the following infrastructure rules are configured:
Node -> Service CIDR IP list (9000/TCP)
Any (0.0.0.0/0 and ::0) -> Node (2379-2380/TCP, 2379-2380/UDP)
ClusterIP Rules
In the CLAS environment, ClusterIP ports are now represented as Kubernetes Workloads when viewing traffic, and not as Virtual Services, as before.
If you want to migrate from a legacy (non-CLAS) to a CLAS environment, you must make sure that all rules that apply to ClusterIP Services are changed to "Use Workloads" at a specific time within the process of upgrading to CLAS. For complete details, see Upgrade to CLAS Architecture.
Because Services are now Kubernetes Workloads, the "All Workloads" flag in a rule will include all Services. Do not use "All Workloads" as a Destination in a rule. Use a more specific label instead that targets the Service.
All rules that include a label of at least one ClusterIP service will have specified ports internally replaced. However - this is not reflected in PCE UI, where the rule still displays ports.
NodePort and LoadBalancer services remain Virtual Services in the PCE. The ClusterIP part of NodePort and LoadBalancer services also exist as a Kubernetes Workload and are linked with the Virtual Service. in the PCE. The ClusterIP part of NodePort and LoadBalancer services also exist as a Kubernetes Workload and are linked with the Virtual Service.
General Traffic View Changes
The following is a summary of general changes to traffic views in a CLAS-enabled cluster:
Kubernetes workloads (for example, Deployments) are now shown in the UI as Kubernetes Workloads, and not as Container Workloads. Container Workloads (Pods) are still shown in non-CLAS clusters.
ClusterIP Virtual Services are now shown as Kubernetes Workloads.
NodePort and LoadBalancer services remain Virtual Services in the PCE.
Traffic from other Virtual Services to Kubernetes Workloads is not shown.
Traffic between Kubernetes Workloads within a cluster is shown.
CLAS Traffic Limitations
Consider the following differences and limitations in these scenarios when viewing traffic and writing rules in a CLAS environment:
Pod to Host
When a Pod is on a different Node than target Node, additional traffic is shown occurring from the Pod's Node to the target Node. This traffic cannot be selectively hidden with filters because it behaves the same way as traffic from host to host that should not be hidden. (This behavior occurs only when Calico is used as the CNI.)
Pod to ClusterIP
Additional direct traffic occurs from a source Pod to a source Target, regardless whether it is destined for the same node or a different target node.
Managed Workload to NodePort
Additional traffic is shown for a Client's direct access to a target Pod, and from a Used Node to a target Pod.
Also, crucial traffic destined for a NodePort is actually showing the Node with the NodePort's port.
Unmanaged Workload (or Internet) to NodePort
Additional traffic is shown for a Client's direct access to a target Pod, and from a Used Node to a target Pod.
Also, in the traffic from the Client to the NodePort virtual service, we are missing the crucial traffic with NodePort's port.
Draft Traffic to Virtual Services
Traffic in Draft mode where the destination is a Virtual Service is marked as Potentially Blocked.