-
Notifications
You must be signed in to change notification settings - Fork 45
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
NodeLocalDNS operator #59
Conversation
Thanks for your pull request. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please follow instructions at https://git.k8s.io/community/CLA.md#the-contributor-license-agreement to sign the CLA. It may take a couple minutes for the CLA signature to be fully registered; after that, please reply here with a new comment and we'll verify. Thanks.
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. I understand the commands that are listed here. |
/uncc |
/assign @stealthybox |
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 really good start!
I have added some general queries in the review
o.Spec.DNSIP = "169.254.20.10" | ||
} | ||
|
||
if o.Spec.ClusterIP == "" { |
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.
Here, we can try to fetch the Cluster IP from the kube-dns
service.
kubectl get svc kube-dns -n kube-system -o jsonpath={.spec.clusterIP}
If we are unable to determine, then we can use the default value.
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 are similar functions in the coredns-operators for finding the ClusterIP and DNS Domain for a cluster. Maybe we could reuse it? Wdyt?
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, we should start to create a shared library of these functions. I think probably in kubebuilder-declarative-pattern, because if e.g. the DNS team takes on ownership of this operator this repo may eventually end up pretty empty :-)
I think we can do this in a follow on PR, if you'd like. (You can add a TODO here so we don't forget)
localnodedns/Dockerfile
Outdated
COPY channels/ channels/ | ||
USER nonroot:nonroot | ||
|
||
ENTRYPOINT ["/manager"] |
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.
Nit: newline
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 file is auto-generated I believe - is this a bug in our kubebuilder plugin?
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 doubt. I edit the file somewhere along the line. But I will generate a new operator and check, to be sure
@@ -0,0 +1 @@ | |||
package controllers |
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 test file seems empty. How are the golden test files generated?
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.
Sorry, That was a mistake
reload | ||
loop | ||
bind 169.254.20.10 10.96.0.10 | ||
forward . __PILLAR__CLUSTER__DNS__ { |
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 __PILLAR__CLUSTER__DNS__
placeholder values should probably be generated properly
Nvm, looks like the automatically updated Corefile values reflected only in the logs as per https://github.com/kubernetes/dns/blob/9903307a652efd77d5de40fdab3bfcd468fd1c74/cmd/node-cache/app/configmap.go#L67
reload | ||
loop | ||
bind 169.254.20.10 10.96.0.10 | ||
forward . __PILLAR__UPSTREAM__SERVERS__ { |
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 __PILLAR__UPSTREAM__SERVERS__
placeholder values should probably be generated properly
Nvm, looks like the automatically updated Corefile values reflected only in the logs as per https://github.com/kubernetes/dns/blob/9903307a652efd77d5de40fdab3bfcd468fd1c74/cmd/node-cache/app/configmap.go#L67
path: Corefile.base | ||
--- | ||
apiVersion: app.k8s.io/v1beta1 | ||
kind: Application |
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.
Does node-local-cache need/use an application?
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 actually thought all addons needed an application. What qualifies an addon to use an application?
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 don't require an application.
I think it's a good idea to have one, it means we have a consistent object that groups the addon contents. Some UIs (for example GKE's) will display Applications nicely.
I know sig-apps is having some debates about Application, but until we have something better, I think we want something, so let's use an Application. If something better comes along, we can then easily replace Applications with new-thing!
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.
Aah, makes sense. I should add one for the coredns operator then.
localnodedns/Dockerfile
Outdated
COPY channels/ channels/ | ||
USER nonroot:nonroot | ||
|
||
ENTRYPOINT ["/manager"] |
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 file is auto-generated I believe - is this a bug in our kubebuilder plugin?
path: Corefile.base | ||
--- | ||
apiVersion: app.k8s.io/v1beta1 | ||
kind: Application |
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 don't require an application.
I think it's a good idea to have one, it means we have a consistent object that groups the addon contents. Some UIs (for example GKE's) will display Applications nicely.
I know sig-apps is having some debates about Application, but until we have something better, I think we want something, so let's use an Application. If something better comes along, we can then easily replace Applications with new-thing!
operator: "Exists" | ||
containers: | ||
- name: node-cache | ||
image: k8s.gcr.io/k8s-dns-node-cache:1.15.13 |
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 going to be annoying feedback, so I'm sorry in advance...
Should we name it "LocalNodeDNS" or "NodeLocalDNS" or "DNSNodeCache"? We want to be consistent with other names.
I've always personally called in NodeLocalDNS. We should probably pick whatever name is most commonly used (with luck, that will be LocalNodeDNS!).
The names inside the code don't matter as much as the CRD name - it's the CRD name that users will interact with.
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 the "official" name is NodeLocalDNS (I'm using https://github.com/kubernetes/kubernetes/tree/release-1.18/cluster/addons/dns/nodelocaldns as reference), so I think we should follow 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.
I think NodeLocalDNS is the one that is most commonly use. Should I manually change all occurrences of the name(I think this is error-prone) or generate a new operator with the new name.
o := object.(*api.LocalNodeDNS) | ||
kubeProxyMode, err := findKubeProxyMode(ctx, mgr.GetClient()) | ||
if err != nil { | ||
fmt.Println("Error determining kube-proxy mode: Defaulting to iptables") |
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.
In general, use logging functions over stdout / stderr. So either klog.Warningf("error determining kube-proxy mode...
) or log.Log("error determining kube-proxy mode...
.
You also should include the error, otherwise it's really hard for someone that sees the log to know what went wrong; for example:
klog.Warningf("error determining kube-proxy mode, defaulting to iptables: %v", err)
I think log has a dedicated helper:
log.Error(err, "error determining kube-proxy mode, defaulting to iptables")
Logging in kubernetes is generally in flux right now; we're moving to structured logging (log) but doing so by adding it to klog (I think) https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1602-structured-logging
o.Spec.DNSIP = "169.254.20.10" | ||
} | ||
|
||
if o.Spec.ClusterIP == "" { |
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, we should start to create a shared library of these functions. I think probably in kubebuilder-declarative-pattern, because if e.g. the DNS team takes on ownership of this operator this repo may eventually end up pretty empty :-)
I think we can do this in a follow on PR, if you'd like. (You can add a TODO here so we don't forget)
This looks good @somtochiama (and thanks @rajansandeep for the reviews!). I apologize for this, but we should figure out what name we want to use. I think the most common terms were LocalNodeDNS or LocalNodeDNSCache based on some basic google searching; but if we can justify the existing name then that's fine too! |
Thanks for renaming - for other tweaks (e.g. sharing functions that you've now put into the kubebuilder-declarative-pattern library :-) ) I think we can merge + iterate /aprpove |
/approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: justinsb, SomtochiAma 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 |
This is for the localnodedns operator