-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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 deployment files #4
Conversation
kind: Deployment | ||
metadata: | ||
name: metrics-server | ||
namespace: kube-system |
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 shouldn't go into kube-system
. We need to limit the number of pods created in this namespace since pods mount SA tokens and the SA tokens in kube-system
are very powerful. You should create your own namespace, probably kube-metrics
to contain this data.
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 a replacement for Heapster which runs in kube-system
and this will run of the the box in every Kubernetes cluster so I think kube-system
is an appropriate namespace 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.
@piosz I think the point is -- "heapster runs in kube-system
which is suboptimal. Let's change that when we do this disruptive change anyway"
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.
@piosz I think the point is -- "heapster runs in kube-system which is suboptimal. Let's change that when we do this disruptive change anyway"
Correct. Separating components into different namespaces helps us reason about which areas have access to particular escalation powers. kube-system
is a super-powered namespace that heapster doesn't need access to. The final goal is zero pods in kube-system
.
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.
so... as an operator, I kind of like having all the k8s services in one namespace. These comments seem to conflate the default service account in kube-system with the namespace itself? Can't we just make a service account for metrics-server and use that in the kube-system namespace instead?
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.
Changing to the other namespace is problematic:
- addon manager only consider pods running in kube-system
- rescheduler the same
- I strongly believe that there are some other parts of the code (maybe in Kubernetes, definitely outside) that relies on the fact that system components run in kube-system
I'm not against but I don't want to handle all that stuff as a part of metrics-server effort.
command: | ||
- /metrics-server | ||
- --source=kubernetes.summary_api:'' | ||
- --requestheader-client-ca-file=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt |
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.
You shouldn't use this as your request header CA file. The request header CA is used to identify your front proxy, but the CA from an SA token is used to identify the kube-apiserver
. You don't want to accidentally allow certs signed by this CA to be used as valid proxies.
The command ought to auto-discover this from the configmap in kube-system
. Otherwise, package and pass the correct CA.
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.
@deads2k do you have a diagram anywhere of how all the different servers fit together along with the CA and certificate files?
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.
@deads2k do you have a diagram anywhere of how all the different servers fit together along with the CA and certificate files?
I don't think we ever made one. All these flags are "normal" flags that operate the same way they're used for the kube-apiserver
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 do think it would still be useful, as I don't have a good understanding of what goes where yet.
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 have a document I submitted that should answer this question. It's in the apiserver-builder repo: https://github.com/kubernetes-incubator/apiserver-builder/blob/master/docs/concepts/auth.md
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.
Again my fault. Until kubernetes/kubernetes#43716 is fixed this is a work-around/hack to allow development to proceed. Once its fixed we will no longer need the work-around.
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.
kubeadm that already sets the proxy flags don't need 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.
@deads2k I thought it's not required but without that apiserver complained about this.
@cheftako since kubernetes/kubernetes#43716 is fixed, am I able to remove this flag now?
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.
removed
- --requestheader-client-ca-file=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt | ||
volumeMounts: | ||
- name: ssl-certs | ||
mountPath: /etc/ssl/certs |
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 recognize this path. What is using the values from here, what is contained, and what are they used for? I'd suggest using the "normal" parameters whenever possible to ease people reading them.
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's for ca certificates. That could probably be copied into the container image instead...
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.
TBH I don't fully understand why we need this here and in a number of other places, but this is a kind of standard in a number of deployments. Should this run without it?
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.
@piosz Test removing it. If it starts failing (which I don't think it will), add it back. Otherwise, remove it, as it adds an unnecessary dependency on the host.
IIUC, the metrics server won't ever hit public domains like google.com
, will it?
That's why CA certificates would be required, to verify the authenticity of normal sites...
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.
removed
deploy/user-role.yaml
Outdated
kind: ClusterRole | ||
metadata: | ||
labels: | ||
kubernetes.io/bootstrapping: rbac-defaults |
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.
You shouldn't apply this annotation yourself. It's for bootstrap roles and this is an add-on
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.
removed file as it's useless
deploy/auth-user.yaml
Outdated
name: metrics-server | ||
subjects: | ||
- kind: User | ||
name: system:anonymous |
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 looks off. You're granting anonymous the ability to read metrics which implies the ability to learn node and pod names? Why?
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 partly my fault, Piotr borrowed some of my test setup. I had done this locally to make it easy for me to test. I think we should either determine the correct users allowed to read metrics or describe to the customer how to set up read permissions for their users.
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 bound to the SA of the metrics-server instead?
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.
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.
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'd like to have access to metrics through apiserver. Without this I wasn't able to do it.
@deads2k @cheftako what should I do instead here?
I suspect that means that your proxy configuration is messed up somehow. Try turning on the audit log in your metrics server and see if all requests appear as unauthenticated. Allowing unrestricted access to metrics isn't suitable.
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.
removed file as it's useless
deploy/auth-user.yaml
Outdated
@@ -0,0 +1,12 @@ | |||
apiVersion: rbac.authorization.k8s.io/v1beta1 |
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.
filename looks weird.
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.
removed file as it's useless
deploy/auth-delegator.yaml
Outdated
@@ -0,0 +1,13 @@ | |||
apiVersion: rbac.authorization.k8s.io/v1alpha1 |
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 you want this to work on GKE I believe you need to use at least the v1beta1 version of core resources such as rbac.
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 beta
deploy/auth-reader.yaml
Outdated
@@ -0,0 +1,14 @@ | |||
apiVersion: rbac.authorization.k8s.io/v1alpha1 |
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.
Ditto
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 beta as well
deploy/auth-user.yaml
Outdated
name: metrics-server | ||
subjects: | ||
- kind: User | ||
name: system:anonymous |
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 partly my fault, Piotr borrowed some of my test setup. I had done this locally to make it easy for me to test. I think we should either determine the correct users allowed to read metrics or describe to the customer how to set up read permissions for their users.
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'd love to try this out soon...
- --requestheader-client-ca-file=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt | ||
volumeMounts: | ||
- name: ssl-certs | ||
mountPath: /etc/ssl/certs |
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's for ca certificates. That could probably be copied into the container image instead...
name: metrics-server | ||
namespace: kube-system | ||
labels: | ||
kubernetes.io/name: "Metrics-server" |
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.
Metrics-Server or metrics-server?
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 other services start with capital letter:
https://github.com/kubernetes/kubernetes/tree/master/cluster/addons/cluster-monitoring/influxdb
deploy/metrics-apiservice.yaml
Outdated
name: v1alpha1.metrics | ||
spec: | ||
insecureSkipTLSVerify: true | ||
group: metrics |
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.
why not metrics.k8s.io or something like that?
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.
Legacy reasons, mostly. It's already just "metrics" in the code. We'd probably eventually want to move to "metrics.k8s.io" when we move to beta.
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.
Yeah, I followed what is in metrics repos. I'm not convinced that we want to change this though. Do we plan to change autoscaling
to autoscaling.k8s.io
? I think metrics
api group is a first class api group in Kubernetes (whatever it means) similarly to apps
or autoscaling
. Only due to performance reasons it's implemented through another apiserver.
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.
"first class" vs non-"first class" is not precisely the issue here (also, IIRC, some of the built-in versions are getting fully-qualified as well). We should keep metrics
as the group name for backwards compat, but the eventual trend is to move to qualified group names, AFAIK.
We should eventually move to resource-metrics.metrics.k8s.io
or something of the sort (as opposed to custom-metrics.metrics.k8s.io
, which is the CM group), but probably not until we move to beta, or something like that.
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 keep metrics as the group name for backwards compat, but the eventual trend is to move to qualified group names, AFAIK
Why not do that now, while you're in alpha and can change things? I don't understand
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.
Why not do that now, while you're in alpha and can change things? I don't understand
Seconded.
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's change this as a part of moving api to beta (outside of the scope of this PR)
command: | ||
- /metrics-server | ||
- --source=kubernetes.summary_api:'' | ||
- --requestheader-client-ca-file=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt |
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.
kubeadm that already sets the proxy flags don't need this, right?
deploy/auth-user.yaml
Outdated
name: metrics-server | ||
subjects: | ||
- kind: User | ||
name: system:anonymous |
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 bound to the SA of the metrics-server instead?
@cheftako @deads2k @DirectXMan12 @kfox1111 @luxas @ncdc Apologies for the delay - it's been evicted by higher priority work. I'm not able to release |
/assign @luxas |
I'll take a look later |
@@ -0,0 +1,12 @@ | |||
apiVersion: rbac.authorization.k8s.io/v1beta1 |
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 has moved to v1: kubernetes/kubernetes#49642
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.
so fast:D
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.
Didn't see anything particularly suspicious.
Depending on what version you're targeting, use these API groups:
v1.7 & v1.8:
- rbac.authorization.k8s.io/v1beta1
- extensions/v1beta1
v1.8+:
- rbac.authorization.k8s.io/v1
- apps/v1beta2
ping |
Sounds reasonable. |
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
The nits I left there are non-blocking
service: | ||
name: metrics-server | ||
namespace: kube-system | ||
group: metrics |
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.
Again, why not move to metrics.k8s.io
now when we can?
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.
Will do once kubernetes/kubernetes#51653 is merged.
group: metrics | ||
version: v1alpha1 | ||
insecureSkipTLSVerify: true | ||
groupPriorityMinimum: 100 |
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.
Are these two values actually the recommended ones? IIRC one of them should be higher
Merging - in case of more comments I'll address them in a follow up PR. |
…_tools Bump release tools
Vulnerability kubernetes-sigs#1: GO-2024-2611 Infinite loop in JSON unmarshaling in google.golang.org/protobuf More info: https://pkg.go.dev/vuln/GO-2024-2611 Module: google.golang.org/protobuf Found in: google.golang.org/protobuf@v1.32.0 Fixed in: google.golang.org/protobuf@v1.33.0 Example traces found: kubernetes-sigs#1: json.Decoder.Peek kubernetes-sigs#2: json.Decoder.Read kubernetes-sigs#3: protojson.Unmarshal kubernetes-sigs#4: protojson.UnmarshalOptions.Unmarshal Signed-off-by: Damien Grisonnet <dgrisonn@redhat.com>
cc @ncdc @deads2k @cheftako