-
Notifications
You must be signed in to change notification settings - Fork 39.6k
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 insertId generation, and update Stackdriver Logging Agent image to 0.5-1.5.36-1-k8s. #68920
Conversation
Hi, could someone help with adding a |
/ok-to-test |
/lgtm |
/assign @MaciekPytel |
Just added some tolerations for Metadata Agent to fix the issue where Metadata Agents are not scheduled. PTAL @x13n @MaciekPytel |
@@ -56,6 +56,13 @@ spec: | |||
dnsPolicy: ClusterFirst | |||
restartPolicy: Always | |||
schedulerName: default-scheduler | |||
tolerations: | |||
- key: "node.alpha.kubernetes.io/ismaster" |
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.
Below you are adding a toleration for all keys with NoSchedule effect, so this one doesn't seem to be doing anything.
/lgtm |
- operator: "Exists" | ||
effect: "NoExecute" | ||
- operator: "Exists" | ||
effect: "NoSchedule" |
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.
Do we really want such strong tolerations? This will make this able to schedule anywhere, including for example a node that is currently being deleted or a super-expensive node with GPU.
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.
This is what we currently have for fluentd and they should really go together. If this is more restricted, then fluentd should be more restricted, too.
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.
Ah, so this is meant to run on every node? In this case it makes much more sense.
What about metadata-agent-cluster-level
below though? If it's one-per-cluster than presumably it should schedule on a node without taints, no?
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. Yes, I think the cluster level one should respect taints.
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 do want all cluster level Metadata Agent to be scheduled though. Otherwise we lose insight of the metadata. It's intentional to disregard the taints. Note that this will only apply to customers who enable the Metadata Agent addons.
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.
@x13n - Yeah, Heapster
does use CriticalAddonsOnly
kubernetes/cluster/addons/cluster-monitoring/stackdriver/heapster-controller.yaml
Line 126 in 2e0e168
- key: "CriticalAddonsOnly" |
As I read this guaranteed-scheduling-critical-addon-pods doc to understand a bit more about what it does, and it sounds like CriticalAddonsOnly
will be deprecated soon. Instead, it recommends priorityClass.
And I did find a priorityClassName
spec defined for Heapster:
kubernetes/cluster/addons/cluster-monitoring/stackdriver/heapster-controller.yaml
Line 48 in 2e0e168
priorityClassName: system-cluster-critical |
We probably should just use priorityClassName: system-cluster-critical
for Logging and Metadata Agents then?
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.
@x13n @MaciekPytel Friendly ping.
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.
https://kubernetes.io/docs/concepts/configuration/pod-priority-preemption/ says this feature is in beta starting from 1.11. You can add it, but don't cherrypick it to 1.10 branch later.
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.
Cool. Updated to use priorityClassName: system-cluster-critical
instead. PTAL
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.
PTAL |
/retest |
@@ -28,6 +28,7 @@ spec: | |||
seccomp.security.alpha.kubernetes.io/pod: 'docker/default' | |||
spec: | |||
serviceAccountName: metadata-agent | |||
priorityClassName: system-cluster-critical |
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.
This one is per-node, so probably should be system-node-critical (which is what fluentd-gcp uses already). @bsalamat can you help with getting this 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.
Changed to system-node-critical
.
@bsalamat - Does this look right to you?
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, as @x13n said, it system-node-critical
is the right one to use 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.
Thanks for confirming!
… 0.5-1.5.36-1-k8s and add priorityClassName for Metadata Agent.
/retest |
/lgtm |
Thanks for lgtm. @MaciekPytel Does this look good to you too? |
Btw, I understand this change as correcting the existing behavior, so: |
/approve On the other hand we may need such tolerations to per-node metadata agent. Without them the agent won't schedule on a node with GPU or a node that has been explicitly dedicated for a specific job by user. If we need agent on every node than it probably needs the tolerations. I'd suggest adding back tolerations to per-node metadata agent if we do need it running on every node. /hold |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: MaciekPytel, qingling128, x13n 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 |
@MaciekPytel According to the documentation, critical pods should be marked |
@x13n I understand this part, but AFAIK priorityClass just allows the pod to preempt a lower priority pod if there is no space in the cluster. It doesn't allow bypassing other scheduling constraints (such as taints). |
For Metadata Agent, we expect the behavior to be consistent between cluster level agent and node level agent. The current implementation sounds like what we want. |
/hold cancel |
Created cherry-pick PRs to release branches |
…68920-upstream-release-1.12 Automated cherry pick of #68920: Enable insertId generation, update Stackdriver Logging Agent
…68920-upstream-release-1.11 Automated cherry pick of #68920: Enable insertId generation, update Stackdriver Logging Agent
What this PR does / why we need it:
Enable insertId generation, and update Stackdriver Logging Agent image to 0.5-1.5.36-1-k8s. This help reduce log duplication and guarantee log order.
Which issue(s) this PR fixes (optional, in
fixes #<issue number>(, fixes #<issue_number>, ...)
format, will close the issue(s) when PR gets merged):Fixes #
Special notes for your reviewer:
Release note: