[01:01:37] tomorrow is WMF holiday and Friday I took PTO, cu Monday [01:02:13] o/ see you [01:03:18] thanks legoktm, I almost forgot about that. enjoy it as well [07:55:19] good morning! [07:56:16] naive questions about network policies: when I have a situation like POD-A -> k8s-svc -> POD-B, I cannot use the pod selector rules to say "only POD-A's label can contact port Y of POD-B" right? [07:57:21] in my case I wanted to instruct the Knative Activator pod (that sometimes acts as loadbalancer in front of backend pods) to accept traffic only from Istio Gateway's pod [07:57:33] but if I add the ingress rule then no traffic flows :D [07:58:05] if I remove the bits related to the label pod selector, it works (so basically allowing traffic to a specific port without restrictions) [08:38:54] elukey: AIUI k8s Services are transparent to network policies. E.g. the "POD-A -> k8s-svc -> POD-B" should work when alowing Pod-A to egress to Pod-B and Pod-B to ingress from Pod-A [08:39:29] As long as you don't have masquarade-all enabled in cluster [08:40:02] I thought the same but I wanted to ask, maybe the traffic doesn't come from the istio pods [08:40:12] (in theory it should) [08:40:57] so in your scenario istio-ingressgateway is Pod-A and knative activator Pod-B? [08:48:02] exactly [08:48:35] or better, both ingress gateways (I also have a cluster-local one) [08:48:40] so in my policy I have [08:48:52] - from: [08:48:52] - podSelector: [08:48:52] matchLabels: [08:48:52] istio: ingressgateway [08:48:52] - podSelector: [08:48:54] matchLabels: [08:48:57] istio: cluster-local-gateway [08:49:03] that IIUC it should be OR-red [08:49:08] *OR-ed [08:49:24] yes [08:49:30] in the middle there is an activator svc [08:50:38] did you already try to verify that the destination of said traffic is when it arrives at the activator Pod? [08:51:31] what do you mean? [08:52:20] sorry...lacking coffee [08:52:44] what I meant was: Did you try to verify the *source* of said traffic :-) [08:53:12] like tcpdump in context of the activator to check if the source is actuall yan ingressgateway ip [08:53:26] yes yes this is the next step :) [08:53:41] never tcpdumped in the context of pods though [08:54:05] nsenter and then everything is like always :) [08:54:54] perfect will do ;) [13:31:50] 10serviceops, 10Prod-Kubernetes, 10Kubernetes, 10Patch-For-Review: Provision TLS certificates for k8s services in istio-system namespace - https://phabricator.wikimedia.org/T295385 (10JMeybohm) [13:32:18] 10serviceops, 10CFSSL-PKI, 10Infrastructure-Foundations, 10Prod-Kubernetes, and 2 others: Automate issuing of TLS certificates in kubernetes clusters - https://phabricator.wikimedia.org/T294560 (10JMeybohm) [13:37:11] very interesting - from the tcpdump I see that inference.svc.eqiad.wmnet is the source of the traffic to the activator's svc [14:18:29] elukey: the lvs ip? [14:18:48] jayme: yep it seems so [14:19:31] elukey: the nodes to have that IP right? [14:20:51] jayme: sorry didn't get the question [14:21:35] ah you meant if the worker nodes have the ip as loopback [14:21:36] yes yes [14:21:57] yeah. I was thinking that the source ip gets rewritten somewhere [14:22:05] when leaving a node [14:24:26] but AIUI that should not happen without the masquarade-all flag [14:28:55] I'd say it's probably fair to say the platform/serviceops sync isn't going to happen today given the US holiday [14:31:32] hnowlan: indeed [14:50:30] <_joe_> hnowlan: yeah let's just avoid showing up :)