-
Notifications
You must be signed in to change notification settings - Fork 39.8k
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
Enable iptables -w in kubeadm selfhosted #46372
Enable iptables -w in kubeadm selfhosted #46372
Conversation
I approve, but it's only a soft approve as I don't know this code very well :-) One option to skip the file-already-exists problem is to mount |
Thanks @justinsb . I did not go with this option initially since @bboreham mentioned that it would probably introduce other bugs #46103 (comment). |
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.
Have you tested that this fixes the issue?
Basically LGTM
@@ -87,6 +90,9 @@ spec: | |||
- name: kube-proxy | |||
configMap: | |||
name: kube-proxy | |||
- name: xtables-lock | |||
hostpath: |
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 think it should be hostPath
I'm deferring to @bboreham on this one as he's the author of the linked issue |
This part is still open:
AFAIK this would be somewhere like |
218c487
to
ae8f230
Compare
@luxas Any pointers on where I would do the touch for making sure that the file exists? |
I can't filter through the log files @k8s-bot pull-kubernetes-unit test this |
@k8s-bot pull-kubernetes-e2e-kops-aws test this |
ae8f230
to
9030969
Compare
@@ -64,6 +64,16 @@ spec: | |||
labels: | |||
k8s-app: kube-proxy | |||
spec: | |||
initContainers: | |||
- name: touch-lock | |||
image: busybox |
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.
Must be an image that's compatible with all architectures
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.
May be related #46820
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.
@luxas Do we have some examples of a generic cross ARCH image?
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.
@ixdy ^
I think we have a gcr.io image of it somewhere. The hard question is security updates for that one @timstclair
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 image needs to be templated to be cross arch. For this type of simple command, we usually just use busybox (though I'd like to switch to alpine). E.g.
kubernetes/cluster/images/etcd/Makefile
Line 37 in 25aed0a
ifeq ($(ARCH),amd64) |
@@ -87,6 +100,9 @@ spec: | |||
- name: kube-proxy | |||
configMap: | |||
name: kube-proxy | |||
- name: xtables-lock | |||
hostPath: | |||
path: /run/xtables.lock |
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.
Is this a file or directory? I suppose file. Will k8s always mount it as a file as well?
- name: touch-lock | ||
image: busybox | ||
command: ['/bin/touch', '/run/xtables.lock'] | ||
securityContext: |
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.
Should this be for pod or init container?
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.
Good point, it should probably just be put at the pod level
command: ['/bin/touch', '/run/xtables.lock'] | ||
securityContext: | ||
privileged: true | ||
volumeMounts: |
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.
Meant for the init container, right?
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.
yes, the run mount is only for the init container
privileged: true | ||
volumeMounts: | ||
- mountPath: /run | ||
name: run |
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 see any run volume
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.
added
9030969
to
4ffbbfe
Compare
This seems relevant |
4ffbbfe
to
bc2f558
Compare
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.
LGTM for everything but the busybox
constant.
xref: #47212 |
bc2f558
to
4e06358
Compare
@@ -64,6 +64,14 @@ spec: | |||
labels: | |||
k8s-app: kube-proxy | |||
spec: | |||
initContainers: | |||
- name: touch-lock | |||
image: {{ .ImageRepository }}/busybox-{{ .Arch }} |
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.
@timstclair @luxas does this look better?
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.
@ixdy We'd have to push an gcr.io/google_containers/busybox-${ARCH} image then (totally possible), don't know if that's feasible from a security standpoint (we'd have to keep it up to date)
cc @timstclair @thockin Please chime in with your thoughts 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.
While it would be great to get this merged, I'm inclined to await #46597 to land and then I can remove the init container.
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.
@cmluciano How critical is this? Can we afford not having this in v1.7?
Where is the related bug/issue?
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.
If kube-proxy is containerized, I believe that it will not properly function. cc @bboreham for confirmation
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.
If it doesn't work at all, it's a release blocker
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.
We should use the upstream busybox images. gcr.io/google-containers won't be kept up to date.
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.
@cmluciano Actually you can use upstream images, but that will add more logic. In this case it seems like the only approach.
So add {{ .BusyboxImage }}
or similar and set it conditionally:
GOARCH | Image |
---|---|
amd64 | busybox |
arm | armhf/busybox |
arm64 | aarch64/busybox |
ppc64le | ppc64le/busybox |
s390x | s390x/busybox |
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.
Let me test with #47212 quick and see if that will work as an interim
4e06358
to
8bc3c8a
Compare
/retest job is marked as flaky |
#47212 would be the better solution yeah |
Currently containerized kube-proxy cannot support iptables -w unless the xtables.lock is mounted. Signed-off-by: Christopher M. Luciano <[email protected]>
8bc3c8a
to
289c37a
Compare
Ok all tests are passing now @luxas. I am going to push up a TODO on this line to rebase on #46597 when it is merged and I opened kubernetes/kubeadm#298 to track it. |
/retest seems like a cleanup issue |
cc @dchen1107 @yujuhong @MrHohn @freehan FYI This is a bug fix for v1.7 |
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: cmluciano, luxas Associated issue: 46103 The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these OWNERS Files:
You can indicate your approval by writing |
/retest |
Automatic merge from submit-queue (batch tested with PRs 47084, 46016, 46372) |
Automatic merge from submit-queue (batch tested with PRs 47451, 47410, 47598, 47616, 47473) kubeadm: Fix kube-proxy regression caused by #46372 **What this PR does / why we need it**: Fixes: kubernetes/kubeadm#306 **Which issue this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close that issue when PR gets merged)*: fixes # **Special notes for your reviewer**: Required for kubeadm v1.7 to work **Release note**: ```release-note NONE ``` @kubernetes/sig-cluster-lifecycle-pr-reviews @cmluciano
Currently containerized kube-proxy cannot support iptables -w
unless the xtables.lock is mounted.
Related: #46103
Signed-off-by: Christopher M. Luciano [email protected]
Special notes for your reviewer:
Release note: