New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Added Windows KEP clarification on ICMP protocol support. #824
Conversation
Hi @daschott. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/ok-to-test |
/LGTM |
@@ -153,6 +154,10 @@ Note that some features are plain unsupported while some will not work without u | |||
- Not all features of shared namespaces are supported. This is clarified in the API section below | |||
- The existing node problem detector is Linux-only and requires privileged containers. In general, we don't expect these to be used on Windows because there's no privileged support | |||
- Overlay networking support in Windows Server 1803 is not fully functional using the `win-overlay` CNI plugin. Specifically service IPs do not work on Windows nodes. This is currently specific to `win-overlay`; other CNI plugins (OVS, AzureCNI) work. Since Windows Server 1803 is not supported for GA, this is mostly not applicable. We left it here since it impacts beta | |||
- Outbound communication using the ICMP protocol via the `win-overlay`, `win-bridge`, and `Azure-CNI` plugin. Specifically, the Windows data plane ([VFP](https://www.microsoft.com/en-us/research/project/azure-virtual-filtering-platform/)) doesn't support ICMP packet transpositions. This means: | |||
- ICMP packets directed to destinations within the same network (e.g. pod to pod communication via ping) will work as expected and without any limitations |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wow. I don't think we document that ICMP should work anywhere. I searched kubernetes.io docs and didn't find it.
Do we have tests for ICMP?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we ever specified it. pod-to-pod ping is really useful for debugging only, but things like ICMP reject are pretty important between nodes or for services with no endpoints.
Ping to the outside world is something I use for debug. I honestly have no idea if breaking this is going to be a big deal. I assume the same breakage holds for ICMP reject or other control signals? That's a pretty weird thing to break, but I am not sure it is a critical gap.
Can we bring this up at sig-net next week, or can you start an email thread on sig-net?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally speaking, you can replace ping <destination>
with curl <destination>
to be able to debug connectivity to the outside world. Yes, I can bring it up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@daschott can you please add this to the docs as well that the alternative is curl/powershell to test connectivity. Once we hear back from the discussion with sig-network we can remove the hold.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought CNI provides IP. ICMP is IP, right?
cc @kubernetes/sig-network-pr-reviews |
Looks like ICMP is not supported as an explicit container protocol: But is supported by NetworkPolicy? |
@daschott @PatrickLang I suggest asking what is expected to work wrt ICMP on the SIG Network mailing list. |
@daschott - is there any outstanding feedback on how this is worded? I think we should merge this so it's accurate with what's implemented. If SIG-Network has outstanding discussions on how ICMP is or should be implemented in the future I think those should be tracked as separate issues, document and adds tests to get ICMP into conformance for a later release. |
/milestone v1.14 |
@@ -153,6 +154,11 @@ Note that some features are plain unsupported while some will not work without u | |||
- Not all features of shared namespaces are supported. This is clarified in the API section below | |||
- The existing node problem detector is Linux-only and requires privileged containers. In general, we don't expect these to be used on Windows because there's no privileged support | |||
- Overlay networking support in Windows Server 1803 is not fully functional using the `win-overlay` CNI plugin. Specifically service IPs do not work on Windows nodes. This is currently specific to `win-overlay`; other CNI plugins (OVS, AzureCNI) work. Since Windows Server 1803 is not supported for GA, this is mostly not applicable. We left it here since it impacts beta | |||
- Outbound communication using the ICMP protocol via the `win-overlay`, `win-bridge`, and `Azure-CNI` plugin. Specifically, the Windows data plane ([VFP](https://www.microsoft.com/en-us/research/project/azure-virtual-filtering-platform/)) doesn't support ICMP packet transpositions. This means: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does transpositions
mean here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The set of operations that perform modifications to network packets such as for example NAT'ing destination or source IPs.
@bgrant0607 @michmike @PatrickLang this was discussed during SIG-network meeting on 02/21. URL here for the meeting: https://www.youtube.com/watch?v=f1NGvMU5GiE |
/hold cancel |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: daschott, michmike, PatrickLang The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
Some common network utilities (e.g. ping, traceroute) used for troubleshooting and diagnosis are based on ICMP messaging. This commit is adding a clarification on what network flows can be expected to work are on Windows containers using the ICMP protocol.