mirror of https://github.com/linkerd/linkerd2.git
3 Commits
Author | SHA1 | Message | Date |
---|---|---|---|
|
77add64860
|
Remove extra three dashes from helm templates (#5628)
(Background information) In our company we are checking the sops-encrypted Linkerd manifest into GitHub repository, and I came across the following problem. --- Three dashes mean the start of the YAML document (or the end of the directive). https://yaml.org/spec/1.2/spec.html#id2800132 If there are only comments between `---`, the document is empty. Assume the file which include an empty document at the top of itself. ```yaml --- # foo --- apiVersion: v1 kind: Namespace metadata: name: foo --- # bar --- apiVersion: v1 kind: Namespace metadata: name: bar ``` When we encrypt and decrypt it with [sops](https://github.com/mozilla/sops), the empty document will be converted to `{}`. ```yaml {} --- apiVersion: v1 kind: Namespace metadata: name: foo --- apiVersion: v1 kind: Namespace metadata: name: bar ``` It is invalid as k8s manifest ([apiVersion not set, kind not set]). ``` error validating data: [apiVersion not set, kind not set] ``` --- I'm afraid that it's sops's problem (at least partly), but anyhow this modification is enough harmless I think. Thank you. Signed-off-by: Takumi Sue <u630868b@alumni.osaka-u.ac.jp> |
|
|
0ce9e84a94
|
Introduce V1 to CRDs and Mutating Hooks (#5603)
*Closes #5484* ### Changes --- *Overview*: * Update golden files and make necessary spec changes * Update test files for viz * Add v1 to healthcheck and uninstall * Fix link-crd clusterDomain field validation - To update to v1, I had to change crd schemas to be version-based (i.e each version has to declare its own schema). I noticed an error in the link-crd (`targetClusterDomain` was `targetDomainName`). Also, additionalPrinterColumns are also version-dependent as a field now. - For `admissionregistration` resources I had to add an additional `admissionReviewVersions` field -- I included `v1` and `v1beta1`. - In `healthcheck.go` and `resources.go` (used by `uninstall`) I had to make some changes to the client-go versions (i.e from `v1beta1` to `v1` for admissionreg and apiextension) so that we don't see any warning messages when uninstalling or when we do any install checks. I tested again different cli and k8s versions to have a bit more confidence in the changes (in addition to automated tests), hope the cases below will be enough, if not let me know and I can test further. ### Tests Linkerd local build CLI + k8s 1.19+ `install/check/mc-check/mc-install/mc-link/viz-install/viz-check/uninstall/` ``` $ kubectl version Server Version: version.Info{Major:"1", Minor:"20", GitVersion:"v1.20.2+k3s1", GitCommit:"1d4adb0301b9a63ceec8cabb11b309e061f43d5f", GitTreeState:"clean", BuildDate:"2021-01-14T23:52:37Z", GoVersion:"go1.15.5", Compiler:"gc", Platform:"linux/amd64"} $ bin/linkerd version Client version: git-b0fd2ec8 Server version: unavailable $ bin/linkerd install | kubectl apply -f - - no errors, no version warnings - $ bin/linkerd check --expected-version git-b0fd2ec8 Status check results are :tick: # MC $ bin/linkerd mc install | k apply -f - - no erros, no version warnings - $ bin/linkerd mc check Status check results are :tick: $ bin/linkerd mc link foo | k apply -f - # test crd creation # had a validation error here because the schema had targetDomainName instead of targetClusterDomain # changed, rebuilt cli, re-installed mc, tried command again secret/cluster-credentials-foo created link.multicluster.linkerd.io/foo created ... # VIZ $ bin/linkerd viz install | k apply -f - - no errors, no version warnings - $ bin/linkerd viz check - no errors, no version warnings - Status check results are :tick: $ bin/linkerd uninstall | k delete -f - - no errors, no version warnings - ``` Linkerd local build CLI + k8s 1.17 `check-pre/install/mc-check/mc-install/mc-link/viz-install/viz-check` ``` $ kubectl version Server Version: version.Info{Major:"1", Minor:"17", GitVersion:"v1.17.17-rc1+k3s1", GitCommit:"e8c9484078bc59f2cd04f4018b095407758073f5", GitTreeState:"clean", BuildDate:"2021-01-14T06:20:56Z", GoVersion:"go1.13.15", Compiler:"gc", Platform:"linux/amd64"} $ bin/linkerd version Client version: git-3d2d4df1 # made changes to link-crd after prev test case Server version: unavailable $ bin/linkerd check --pre --expected-version git-3d2d4df1 - no errors, no version warnings - Status check results are :tick: $ bin/linkerd install | k apply -f - - no errors, no version warnings - $ bin/linkerd check --expected-version git-3d2d4df1 - no errors, no version warnings - Status check results are :tick: $ bin/linkerd mc install | k apply -f - - no errors, no version warnings - $ bin/linkerd mc check - no errors, no version warnings - Status check results are :tick: $ bin/linkerd mc link --cluster-name foo | k apply -f - bin/linkerd mc link --cluster-name foo | k apply -f - secret/cluster-credentials-foo created link.multicluster.linkerd.io/foo created # VIZ $ bin/linkerd viz install | k apply -f - - no errors, no version warnings - $ bin/linkerd viz check - no errors, no version warnings - - hangs up indefinitely after linkerd-viz can talk to Kubernetes ``` Linkerd edge (21.1.3) CLI + k8s 1.17 (already installed) `check` ``` $ linkerd version Client version: edge-21.1.3 Server version: git-3d2d4df1 $ linkerd check - no errors - - warnings: mismatch between cli & control plane, control plane not up to date (both expected) - Status check results are :tick: ``` Linkerd stable (2.9.2) CLI + k8s 1.17 (already installed) `check/uninstall` ``` $ linkerd version Client version: stable-2.9.2 Server version: git-3d2d4df1 $ linkerd check × control plane ClusterRoles exist missing ClusterRoles: linkerd-linkerd-tap see https://linkerd.io/checks/#l5d-existence-cr for hints Status check results are × # viz wasn't installed, hence the error, installing viz didn't help since # the res is named `viz-tap` now # moving to uninstall $ linkerd uninstall | k delete -f - - no warnings, no errors - ``` _Note_: I used `go test ./cli/cmd/... --generate` which is why there are so many changes 😨 Signed-off-by: Matei David <matei.david.35@gmail.com> |
|
|
e7f2a3fba3
|
viz: add tap-injector (#5540)
## What this changes This adds a tap-injector component to the `linkerd-viz` extension which is responsible for adding the tap service name environment variable to the Linkerd proxy container. If a pod does not have a Linkerd proxy, no action is taken. If tap is disabled via annotation on the pod or the namespace, no action is taken. This also removes the environment variable for explicitly disabling tap through an environment variable. Tap status for a proxy is now determined only be the presence or absence of the tap service name environment variable. Closes #5326 ## How it changes ### tap-injector The tap-injector component determines if `LINKERD2_PROXY_TAP_SVC_NAME` should be added to a pod's Linkerd proxy container environment. If the pod satisfies the following, it is added: - The pod has a Linkerd proxy container - The pod has not already been mutated - Tap is not disabled via annotation on the pod or the pod's namespace ### LINKERD2_PROXY_TAP_DISABLED Now that tap is an extension of Linkerd and not a core component, it no longer made sense to explicitly enable or disable tap through this Linkerd proxy environment variable. The status of tap is now determined only be if the tap-injector adds or does not add the `LINKERD2_PROXY_TAP_SVC_NAME` environment variable. ### controller image The tap-injector has been added to the controller image's several startup commands which determines what it will do in the cluster. As a follow-up, I think splitting out the `tap` and `tap-injector` commands from the controller image into a linkerd-viz image (or something like that) makes sense. Signed-off-by: Kevin Leimkuhler <kevin@kleimkuhler.com> |