| *** huntxu has joined #openstack-qinling | 02:11 | |
| lxkong | huntxu: i have question related to `_ensure_network_policy ` method when the k8s orchestrator initializing | 03:16 |
|---|---|---|
| lxkong | according to the method, does that mean the pod cannot be accessed from outside of the k8s cluster? | 03:16 |
| lxkong | https://www.irccloud.com/pastebin/jutpUxA5/ | 03:17 |
| lxkong | this is the networkpolicy in my qinling deployment | 03:18 |
| lxkong | seems yes, i delete that policy and now i can access the service inside the pod from outside the cluster | 03:21 |
| lxkong | that is gonna be a problem | 03:21 |
| lxkong | if qinling and k8s are both deployed separately, qinling-engine can not talk to the runtime pod | 03:22 |
| huntxu | lxkong: what do you mean by "deployed separately"? qinling-engine and k8s pods run on different hosts? | 05:35 |
| huntxu | lxkong: the runtime pod is exposed via a namespaced service on pod preparation, so it's ok for qinling-engine to access the service in the pod via the k8s namespaced service | 05:37 |
| huntxu | lxkong: before that no namespaced service are created, so even the pod is running (not serving for any functions), you cannot access to the service in pod | 05:39 |
| *** mnaser has quit IRC | 06:16 | |
| *** mnaser has joined #openstack-qinling | 06:17 | |
| lxkong | huntxu: i mean, the disable-interpods-connections network policy will block the external access | 06:55 |
| lxkong | so if qinling-engine and k8s is running on different hosts, qinling-engine can not talk to any service exposed by the runtime pods. | 06:56 |
| lxkong | i've already encountered such issue | 06:56 |
| lxkong | i have deployed qinling(without k8s) on vm1, and i have a separate k8s cluster running on vm2 | 06:56 |
| lxkong | after successfully confiugred that connection between them(qinling-engine is running well) | 06:57 |
| lxkong | i found qinling-engine fails to send http request to the service url | 06:57 |
| lxkong | after deleting the network policy, it just works | 06:57 |
| lxkong | in our CI, qinling and k8s is running on a same VM, and that network policy doesn't block the access | 06:58 |
| lxkong | huntxu: is that clear? | 06:59 |
| *** mattgo has joined #openstack-qinling | 08:23 | |
| huntxu | lxkong: Yes I understand the scenario. However when I was testing this, I can successfully access the exposed k8s service (then to the pod) from another host while there is such a network policy | 08:32 |
| huntxu | lxkong: besides it seems to me not a problem related to whether qinling-engine runs on a different host or not. For a k8s cluster, even connections from localhost should be considered as external (not from pods inside the cluster but via a namespaced service), no? | 08:36 |
| lxkong | huntxu: no, from the test i did, that network policy didn't stop connections from the master node | 10:45 |
| lxkong | which sounds...weird | 10:46 |
| lxkong | i have come up with a solution that only allow connection from qinling-engine ip address to the pods of qinling namespace. | 10:47 |
| lxkong | kind: NetworkPolicy | 10:48 |
| lxkong | apiVersion: networking.k8s.io/v1 | 10:48 |
| lxkong | metadata: | 10:48 |
| lxkong | namespace: qinling | 10:48 |
| lxkong | name: allow-external | 10:48 |
| lxkong | spec: | 10:48 |
| lxkong | podSelector: {} | 10:48 |
| lxkong | policyTypes: | 10:48 |
| lxkong | - Ingress | 10:48 |
| lxkong | ingress: | 10:48 |
| lxkong | - from: | 10:48 |
| lxkong | - ipBlock: | 10:48 |
| lxkong | cidr: 10.0.0.11/32 | 10:48 |
| lxkong | shit.. | 10:48 |
| lxkong | https://www.irccloud.com/pastebin/Nf0p5efz/ | 10:49 |
| lxkong | something like this | 10:49 |
| huntxu | lxkong: this is exactly the same solution I had come up with when I first tried to implement the isolation feature. But then I found I could access to the pod via the exposed service from another host, so things became easier then | 10:58 |
| huntxu | lxkong: the problem with this solution is that it is difficult to determine the address that qinling-engine will use to contact the service, especially when there is some NAT between them | 10:59 |
| lxkong | we could make this configurable, if not provided, then no network policy will be created | 11:00 |
| lxkong | allow operator add some ips or cidrs | 11:00 |
| lxkong | documentation is also needed. | 11:01 |
| lxkong | huntxu: btw, could you please merge this one https://review.openstack.org/#/c/613831/? | 11:02 |
| lxkong | i've already tested with `QINLING_INSTALL_K8S=False` | 11:02 |
| huntxu | lxkong: done, I've read that yesterday, but forgot to land it | 11:04 |
| lxkong | thanks | 11:04 |
| *** huntxu has quit IRC | 11:30 | |
| openstackgerrit | Merged openstack/qinling master: Skip k8s installation if needed https://review.openstack.org/613831 | 11:43 |
| *** larainema has joined #openstack-qinling | 11:54 | |
| openstackgerrit | Lingxian Kong proposed openstack/qinling master: Improve the documentation https://review.openstack.org/614199 | 12:16 |
| openstackgerrit | Lingxian Kong proposed openstack/qinling master: Improve the documentation https://review.openstack.org/614199 | 12:34 |
| *** mattgo has quit IRC | 17:22 | |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!