projectcalico/calico

Moved from tigera/operator#1512, opened by @taxilian on 2021-09-10. Original comment thread stays readable at the link above. First, let me clarify that I'm aware that my cluster is misconfigured =] Unfortunately it seems there is no way to fix that without completely rebuilding the cluster, which I don't have time to do right now. I did not realize that calico's IPPool resources still needed to be within the cluster pod CIDR, so I'm using pools that are outside of it -- e.g. 172.25.64.0/20 when my cluster CIDR is 10.172.0.0/16. I didn't realize it mattered, and since I'm using ToR bgp peering 99% of everything still works fine. However, after migrating to the tigera operator (during which I attempted to change my cluster CIDR and discovered that it's either not possible or at least more difficult than expected) the operator won't update anything because it's constantly in an "error" state: Could not resolve CalicoNetwork IPPool and kubeadm configuration: IPPool 172.25.64.0/20 is not

Moved from tigera/operator#2872, opened by @uwebartels on 2023-09-14. Original comment thread stays readable at the link above. tigera is reverting custom labels on namespace calico-system Expected Behavior custom labels for namespaces should be deletable and not be reverted to its former state. Current Behavior Currently I need to delete a custom label on the namespace calico-system. Technically I can do this, but tigera-operator reverts my change within some seconds. Possible Solution Steps to Reproduce (for bugs) add a custom label to the namespace, I don't really know how this was done. remove the label check tigera log output for {"level":"info","ts":1694683553.298883,"logger":"controller_apiserver","msg":"Reconciling APIServer","Request.Namespace":"","Request.Name":"default"} kubectl describe ns calico-system and see that the former deleted label is configured again Context label for the pod-security-webhook are set. they prevent the creation of new nodes - or better to setup

Moved from tigera/operator#3480, opened by @bigkevmcd on 2024-08-28. Original comment thread stays readable at the link above. Expected Behavior Externally added finalizers should be retained across reconciliations by the tigera-controller. Current Behavior Currently, if another controller adds a finalizer to an Operator-created resource, it will get removed on re-reconcile. This commit tigera/operator@beeba82cb fixed this for Kibana resources. tigera/operator@beeba82cb#diff-8a70460893d606f15b2f0b6b4292348d55975719fa6d0a50b32a8e4c148ddf6eR218 We are seeing the same problem, update-battles for some resources that Rancher is adding finalizers to (specifically at least ClusterRoleBindings). Possible Solution Retain the existing finalizers on the resource (by merging with the existing finalizers). Steps to Reproduce (for bugs) Add a finalizer to an operator-created resource e.g. the calico-node ClusterRoleBinding The added finalizer will be removed and the tigera.io/cni-protector

In calico 3.30, I can use ufw to protect hostendpoint connection and use GlobalNetworkPolicy to protect pod-svc connection. After using calico 3.32, I can't use the old way, seem the behaviour of eBPF is different now. (I tested many time...) So I tried to disable ufw, and use GlobalNetworkPolicy to do all the protection. But the behaviour is really strange. Even I disable failsafe rule and apply a StagedGlobalNetworkPolicy for default deny. Whisker didn't show deny record for hostendpoint. But if I apply a GlobalNetworkPolicy for default deny, system will total crash. (I know it is 'of course') If Whisker can't record hostendpoint connection, it is very hard to troubleshoot. I don't know if it is my fault. If yes, please let me know how to set a StagedGlobalNetworkPolicy for whisker to capture hostendpoint connection, so I can setup policy according to them. Expected Behavior Whisker record hostendpoint connection . Current Behavior Whisker didn't record hostendpoint connection .

Expected Behavior When an endpoint is defined with a named port, checker should be able to translate the name to actual ports. Current Behavior In the app-policy checker, a rule that references a named port never matches, so an Allow rule denies by default (and a Deny rule silently does nothing). Possible Solution Extend policy store to get translate the name port via CalcGraph. Steps to Reproduce (for bugs) Define a workload endpoint with a named port, e.g. a port named http 8080. Apply a policy that references it by name: apiVersion: projectcalico.org/v3 kind: GlobalNetworkPolicy metadata: name: allow-http-named-port spec: selector: app == 'server' types: [Ingress] ingress: - action: Allow protocol: TCP destination: ports: [http] Enable Application Layer Policy so the flow is evaluated by the app-policy checker (Dikastes), and send TCP to the endpoint on 8080. Observe the request is denied. The dataplane (non-ALP) allows the same flow. Unit