You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
First of all, let me preface this by saying that I really enjoy Calico. I think it has one of the best/more mature network policy model. We have encouraged others to use it and pushed for Azure to support it more despite their recent stance.
That being said, I do believe that, in the long run, not having this kind of additional observability in the open-source variant might hurt the popularity of Calico.
In our case, we have seen firsthand several other departments opting to go the Cilium route, not because of its policy model or features, but rather simply because of the additional observability provided out of the box.
I think this additional observability would increase the pool of users trying Calico, and by growing this pool, grow the potential conversion to Calico Enterprise/Cloud.
Possible Solution
There are numerous ways to go about this, and obviously Enterprise version should probably maintain superiority of observability.
A potential approach could be:
Simple syslog pod name enrichment
We already have the log action, which can generate syslog of blocked traffic containing the src IP and dst IP. We would simply need to enrich these with pod name, if the IP belongs to a pod within the cluster.
I think this would already be a large improvement for end-users while keeping most of the user friendly/richer features in the Enterprise version.
The text was updated successfully, but these errors were encountered:
First of all, let me preface this by saying that I really enjoy Calico. I think it has one of the best/more mature network policy model. We have encouraged others to use it and pushed for Azure to support it more despite their recent stance.
That being said, I do believe that, in the long run, not having this kind of additional observability in the open-source variant might hurt the popularity of Calico.
In our case, we have seen firsthand several other departments opting to go the Cilium route, not because of its policy model or features, but rather simply because of the additional observability provided out of the box.
I think this additional observability would increase the pool of users trying Calico, and by growing this pool, grow the potential conversion to Calico Enterprise/Cloud.
Possible Solution
There are numerous ways to go about this, and obviously Enterprise version should probably maintain superiority of observability.
A potential approach could be:
Simple syslog pod name enrichment
We already have the log action, which can generate syslog of blocked traffic containing the src IP and dst IP. We would simply need to enrich these with pod name, if the IP belongs to a pod within the cluster.
I think this would already be a large improvement for end-users while keeping most of the user friendly/richer features in the Enterprise version.
The text was updated successfully, but these errors were encountered: