Skip to content
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

Fix coredns based exposure #799

Merged
merged 1 commit into from
Dec 13, 2021
Merged

Fix coredns based exposure #799

merged 1 commit into from
Dec 13, 2021

Conversation

ytsarev
Copy link
Member

@ytsarev ytsarev commented Dec 13, 2021

The issue was detected with AWS reference setup

  • The condition was not working as expected
  • It led to degraded state when we expected k8gb-ns-* DNSEndpoint
    IP addresses to be populated with exposed coredns service ip addresses
    Instead it was not detecting the rule and was populated by Ingress IPs
    creating non-obvious mess in the configuration.

Signed-off-by: Yury Tsarev yury.tsarev@absa.africa

The issue was detected with AWS reference setup

* The condition was not working as expected
* It led to degraded state when we expected `k8gb-ns-*` DNSEndpoint
  IP addresses to be populated with exposed coredns service ip addresses
  Instead it was not detecting the rule and was populated by Ingress IPs
  creating non-obvious mess in the configuration.

Signed-off-by: Yury Tsarev <yury.tsarev@absa.africa>
@somaritane
Copy link
Contributor

Related to #615

Copy link
Contributor

@somaritane somaritane left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ytsarev LGTM, but I think we have to find the way how to also make kube-linter happy about it as well (see #615). The local run will definitely fail. Right now the check from GH actions is useless anyways

@ytsarev ytsarev merged commit dfd3c13 into master Dec 13, 2021
@ytsarev ytsarev deleted the fix-coredns-expo branch December 13, 2021 17:57
@somaritane
Copy link
Contributor

@ytsarev this code renders COREDNS_EXPOSED template properly and also doesn't cause kube-linter errors:

            {{- if eq "LoadBalancer" ( .Values.coredns.serviceType ) }}

@jkremser
Copy link
Member

weirdly enough, the kube-lint installed from brew behaves differently than the one downloaded from internets. Even though it's the same version.

{{- if eq "LoadBalancer" ( .Values.coredns.serviceType ) }} this works w/ kube-lint from brew, but fails w/ the one that's used in the action

 ~/Downloads/kube-linter version
0.2.5
~/Downloads/kube-linter lint -v chart
Warning: failed to load object from chart/k8gb: failed to render: template: k8gb/templates/operator.yaml:102:19: executing "k8gb/templates/operator.yaml" at <eq "LoadBalancer" (.Values.coredns.serviceType)>: error calling eq: incompatible types for comparison
Warning: no valid objects found.

while brew one:

kube-linter version
0.2.5
kube-linter lint -v chart
Warning: failed to load object from chart/k8gb/templates/external-dns/rbac.yaml: failed to decode: Object 'Kind' is missing in '---'
KubeLinter 0.2.5

No lint errors found!

this expression works on both versions, but I can't check if it's ok in the aws context:

{{- if eq "LoadBalancer" ( toString .Values.coredns.serviceType ) }}

@somaritane
Copy link
Contributor

this expression works on both versions, but I can't check if it's ok in the aws context:

{{- if eq "LoadBalancer" ( toString .Values.coredns.serviceType ) }}

@jkremser thanks for finding the working solution! I've checked the proper rendering with helm template and "aws-enabled" custom values yaml file.
I've made the related fix here: #801

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants