Have the Webhook react to pod creation/update only #2472

alpeb · 2019-03-07T22:36:58Z

This was already working almost out-of-the-box, just had to:

Change the webhook config so it watches pods instead of deployments
Grant some extra ClusterRole permissions
Add the piece that figures what's the OwnerReference and add the label
for it

Tested fine when applying new yamls for Deployments and StatefulSets.

alpeb · 2019-03-11T21:43:31Z

This is ready for review now.
One caveat: we're not copying the pod labels into its parent workload (deployment, job, daemonset or statefulset). When using the CLI, that is done automatically by Kubernetes when creating the workload with kubectl apply. And we were doing that manually in the webhook when we were listening to Deployments.
Doing that now that we're only dealing with pod creation/update events would require hitting the Kubernetes API to update those labels, and additional permissions for the proxy-injector ClusterRole.
But if I'm not mistaking those labels aren't really useful. If I'm mistaking, let me know 😉

siggy

not sure if this is my environment, but getting startup failures following auto-injection:

$ kubectl -n emojivoto logs -f pod/vote-bot-644ddf8596-n44tz linkerd-proxy
ERR! linkerd2_proxy::transport::tls::identity Invalid DNS name: [46, 112, 111, 100, 46, 101, 109, 111, 106, 105, 118, 111, 116, 111, 46, 108, 105, 110, 107, 101, 114, 100, 45, 109, 97, 110, 97, 103, 101, 100, 46, 108, 105, 110, 107, 101, 114, 100, 46, 115, 118, 99, 46, 99, 108, 117, 115, 116, 101, 114, 46, 108, 111, 99, 97, 108]
configuration error: InvalidEnvVar

steps to reproduce

bin/linkerd install --proxy-auto-inject --tls optional | kubectl apply -f -

use this gist:

curl https://gist.githubusercontent.com/siggy/867ae15d7e1c48c0d6cb2fb4f92f24d5/raw/5c4f5738e56b19f14dc42faa3773c1da72fae6d5/emojivoto-auto-inject.yml | kubectl apply -f -

Diffing the output of kubectl -n emojivoto get all -oyaml against master reveals a few notable differences:

this branch

      volumeMounts:
      - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
        name: emoji-token-pjdtg
        readOnly: true
...
      - name: LINKERD2_PROXY_ID
        value: .pod.$LINKERD2_PROXY_POD_NAMESPACE.linkerd-managed.linkerd.svc.cluster.local

master

      volumeMounts:
      - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
        name: default-token-rz8qb
        readOnly: true
...
      - name: LINKERD2_PROXY_ID
        value: emoji.deployment.$LINKERD2_PROXY_POD_NAMESPACE.linkerd-managed.linkerd.svc.cluster.local
...
      # this block only present on master
      - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
        name: default-token-rz8qb
        readOnly: true
...
      # this block only present on master
      volumeMounts:
      - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
        name: default-token-rz8qb
        readOnly: true

olix0r · 2019-03-11T23:15:18Z

If this is particularly difficult to fix, I should note that the identity/master branch changes the ID structure such that no parent information need be reference by the injector.

alpeb · 2019-03-12T18:01:51Z

Thanks for the detailed check @siggy! (I'll have to get into the habit of testing things with TLS enabled...)

I tried fixing the LINKERD2_PROXY_ID value by setting it to the pod's "generated name", which would end up something like vote-bot-c78795449-.pod.$LINKERD2_PROXY_POD_NAMESPACE.linkerd-managed.linkerd.svc.cluster.local, but that still doesn't fix the proxy error. Having it refer to the parent deployment would require changes that will need to be discarded afterwards per @olix0r's comment above, so I'm leaving it as is for now.

As for the missing serviceaccount mount paths, I believe the cause is as follows:

TL;DR: The injected sidecar + initContainer don't pass through the Service Account admission controller, so we have to manually add the missing mount paths.

The Service Account admission controller is the one in charge of automatically adding those mounts when a pod enters the system, and that's always run before our mutating admission webhook.

When we were dealing with Deployments, we injected our sidecar and initContainer into the Deployment spec, then that created a Pod which went through the Service Account admission controller and got its mount paths set.

Now that we listen to Pod creation only, the Pod we receive in the webhook has already gone through the Service Account admission controller, which is confirmed by the mount path being correctly set in the uninjected container. We then proceed to inject our containers, but the Pod won't go again through the Service Account admission controller, so the mount path for our new containers won't get set.

As a solution I will be manually adding those mount paths.

siggy

Hmm, I'm still seeing:

$ kubectl -n emojivoto logs -f pod/emoji-7cdf7ff5d-9d94q linkerd-proxy
ERR! linkerd2_proxy::transport::tls::identity Invalid DNS name: [101, 109, 111, 106, 105, 45, 55, 99, 100, 102, 55, 102, 102, 53, 100, 45, 46, 112, 111, 100, 46, 101, 109, 111, 106, 105, 118, 111, 116, 111, 46, 108, 105, 110, 107, 101, 114, 100, 45, 109, 97, 110, 97, 103, 101, 100, 46, 108, 105, 110, 107, 101, 114, 100, 46, 115, 118, 99, 46, 99, 108, 117, 115, 116, 101, 114, 46, 108, 111, 99, 97, 108]
configuration error: InvalidEnvVar

Decoding those bytes yields:

emoji-7cdf7ff5d-.pod.emojivoto.linkerd-managed.linkerd.svc.cluster.local

...maybe the trailing hyphen is a problem?

      - name: LINKERD2_PROXY_ID
        value: emoji-7cdf7ff5d-.pod.$LINKERD2_PROXY_POD_NAMESPACE.linkerd-managed.linkerd.svc.cluster.local

alpeb · 2019-03-12T21:41:23Z

Following up on our conversation, I've disabled --tls optional to avoid hitting these errors. This means this branch will depend on the Identity branch to get merged first.

alpeb · 2019-03-19T16:28:29Z

I've just rebased now that the --tls flag in master has been dropped, so this branch can be reviewed without any disclaimers. The plan is to merge this before #2500, as it simplifies the webhook logic.

klingerf

Nice, glad to see that this is straightforward to setup. I've suggested a different approach below for finding pod owners, so that we don't have to implement owner reference parsing twice in the codebase, but let me know if my comments don't make sense.

controller/proxy-injector/webhook.go

chart/templates/proxy_injector.yaml

pkg/k8s/labels.go

ihcsim

LGTM. Just one question.

controller/proxy-injector/webhook.go

ihcsim · 2019-03-20T20:44:40Z

One TIOLI: I notice there is still a patch = NewPatchDeployment() in GetPatch(). We definitely still need it to support CLI inject of different kinds of workloads. I wonder if we can make it more generic, since those patches work for other non-workload types. (For a second, I thought that only works for Deployment and we somehow broke CLI inject 😆).

One suggestion is to just replace the two constructors with a more general NewPatch() constructor, and use a kind parameter to decide which paths to use.

alpeb · 2019-03-20T21:12:21Z

@ihcsim yeah, NewPatchDeployment is not a generic-enough name hehe. I'll implement your suggestion based on 'Kind` 👍

ihcsim · 2019-03-20T23:04:19Z

In addition to the issue with auto-injecting single pod without labels, there is another minor one. The log msg is missing the workload name:

proxy-injector time="2019-03-20T22:38:55Z" level=info msg="patch generated for: Pod"

I think the ResourceConfig.String() method needs to look for the workload name in podSpec, instead of workLoad.

alpeb · 2019-03-21T15:23:18Z

I think the ResourceConfig.String() method needs to look for the workload name in podSpec, instead of workLoad.

Actually podSpec doesn't hold the pod's name either, so we have to rely on the admission request data. I'll fix that.

alpeb · 2019-03-22T20:19:55Z

Thank you guys for all your feedback. Here's a new push with everything addressed.

@klingerf I'm now using GetOwnerKindAndName() as you suggested, although I finally didn't get to change its signature because it implied lots of changes elsewhere so it wasn't worth it.

@ihcsim Given the payload received by the webhook is a little different in regards to metadata, I had to get rid of the ResourceConfig.String() method, and I'm letting the report produce that string (I also dropped the namespace from there for simplicity).

Sorry I had to rebase one more time, to keep in sync with the Identity changes.

This was already working almost out-of-the-box, just had to: - Change the webhook config so it watches pods instead of deployments - Grant some extra ClusterRole permissions - Add the piece that figures what's the OwnerReference and add the label for it Fixes #2342 and #1751 Signed-off-by: Alejandro Pedraza <[email protected]>

Signed-off-by: Alejandro Pedraza <[email protected]>

ihcsim

Thanks for rebasing with master. Some comments below.

controller/proxy-injector/webhook.go

controller/proxy-injector/webhook_test.go

pkg/inject/inject.go

ihcsim · 2019-03-25T19:19:58Z

pkg/inject/inject.go

@@ -362,10 +355,20 @@ func (conf *ResourceConfig) complete(template *v1.PodTemplateSpec) {
 	conf.pod.Meta = &template.ObjectMeta
 }

+// GetPod returns the parsed object as a *v1.Pod variable
+func (conf *ResourceConfig) GetPod() (*v1.Pod, error) {


Probably not needed if you moved the logic of webhook.getLabelForParent() into this package.

inject.go is not dependent on k8s.API, which is needed in getLabelForParent(). That's why I kept the pod object retrieval logic separated from the logic that retrieves its ownership, which is only used in the webhook.

ihcsim · 2019-03-25T19:32:30Z

pkg/inject/report.go

@@ -27,21 +27,25 @@ func newReport(conf *ResourceConfig) Report {
 	var name string
 	if m := conf.pod.Meta; m != nil {
 		name = m.Name
+		if name == "" {
+			name = m.GenerateName


Not sure how useful this will be, as it only returns the prefix of the pod name like linkerd-controller-7c6b8c586b-. Will there be cases where the pod name will be empty? The parent workload name, if non-empty, might be more useful.

The pod name appears to be always empty in the admission request metadata, and we only have access to that GenerateName, which is actually the ReplicaSet's name (plus a dash). I think this is a bit more informative (linkerd-controller-7c6b8c586b-) than the Deployment's name (linkerd-controller).

klingerf

Great, thanks for switching to k8s.API. Approach looks good to me, but I was a bit confused by the handling of the namespace in the pod meta -- see my comments below. Also had just a few other random bits of feedback.

chart/templates/proxy_injector.yaml

controller/proxy-injector/webhook.go

controller/proxy-injector/webhook_test.go

pkg/inject/inject.go

pkg/inject/report.go

siggy

This all works on my machine. Had mostly questions...

controller/proxy-injector/webhook.go

pkg/inject/inject.go

Signed-off-by: Alejandro Pedraza <[email protected]>

alpeb · 2019-03-25T23:01:13Z

controller/proxy-injector/webhook.go

-			return pkgK8s.ProxyStatefulSetLabel, name, nil
-		}
-		return "", "", fmt.Errorf("unsupported parent kind \"%s\"", kind)
+func (w *Webhook) ownerRetriever(ns string) inject.OwnerRetrieverFunc {


who said go cannot haz curry? 🐱

alpeb · 2019-03-25T23:03:29Z

controller/proxy-injector/webhook_test.go

@@ -154,158 +153,6 @@ func TestGetPatch(t *testing.T) {
 	})
 }

-func TestGetLabelForParent(t *testing.T) {


Given we no longer have GetLabelForParent() I removed this test, but created #2560 to complete the webhook tests, that we can address in the 2.3 testing sprint.

klingerf

⭐️ Looks great! Thanks for making those updates.

cli/cmd/inject.go

pkg/inject/inject.go

pkg/inject/patch_test.go

siggy

thanks for the updates! 👍 🚢

pkg/inject/inject.go

Signed-off-by: Alejandro Pedraza <[email protected]>

l5d-bot · 2019-03-26T16:50:07Z

Integration test results for 122bdb2: success 🎉
Log output: https://gist.github.com/d8684f23238f0c8e0818e4fdc30b63ec

This branch cherry-picks #2472 onto `release/v2.203`. Currently, the proxy [depends on an outdated version of `rustls`][1], v0.20.8. The `rustls` dependency is via our dependency on `tokio-rustls` v0.23.4; we don't have a direct `rustls` dependency, in order to ensure that the version of `rustls` is always the same version as used by `tokio-rustls`. `rustls` also has a dependency on `webpki`, and v0.20.x of `rustls` uses the original `webpki` crate, rather than the `rustls-webpki` crate. So, unfortunately, because we have a transitive dep on `webpki` via `rustls`, PR linkerd/linkerd2-proxy#2465 did not remove _all_ `webpki` deps from our dependency tree, only the direct dependency. This branch updates to `rustls` v0.21.x, which depends on `rustls-webpki` rather than `webpki`, removing the `webpki` dependency. This is accomplished by updating `tokio-rustls` to v0.24.x, implicitly updating the transitive `rustls` dep. In order to update to the semver-incompatible version of `rustls`, it was necessary to modify our code in order to track some breaking API changes. I've also added a `cargo-deny` ban for `webpki` to our `deny.toml`, to ensure that we always use the actively-maintained `rustls-webpki` crate rather than `webpki` classic. Since peer certificate validation is performed through `rustls` rather than through the direct `rustls-webpki` dependency, this should hopefully resolve issues with issuer certs that contain name constraints --- these were not fixed by linkerd/linkerd2-proxy#2465, because the failure with certs containing name constraints occurred inside of the *`webpki` version depended on by `rustls`*, rather than inside of the proxy's direct dep. See [this comment][2] for details. In addition, it was necessary to update `rustls-webpki` to v0.101.6, since v0.101.5 was yanked due to an accidental API breaking change. <details> <summary>Verifying that we no longer depend on `webpki`:</summary> Before: ```console $ cargo tree -p webpki -i webpki v0.22.1 ├── rustls v0.20.8 │ └── tokio-rustls v0.23.4 │ ├── linkerd-app-integration v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/integration) │ └── linkerd-meshtls-rustls v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/meshtls/rustls) │ ├── linkerd-app-inbound v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/inbound) │ │ ├── linkerd-app v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app) │ │ │ ├── linkerd-app-integration v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/integration) │ │ │ └── linkerd2-proxy v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd2-proxy) │ │ ├── linkerd-app-admin v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/admin) │ │ │ └── linkerd-app v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app) (*) │ │ │ [dev-dependencies] │ │ │ └── linkerd-app-integration v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/integration) │ │ └── linkerd-app-gateway v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/gateway) │ │ └── linkerd-app v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app) (*) │ │ [dev-dependencies] │ │ └── linkerd-app-gateway v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/gateway) (*) │ ├── linkerd-app-outbound v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/outbound) │ │ ├── linkerd-app v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app) (*) │ │ └── linkerd-app-gateway v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/gateway) (*) │ │ [dev-dependencies] │ │ └── linkerd-app-gateway v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/gateway) (*) │ └── linkerd-meshtls v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/meshtls) │ ├── linkerd-app-core v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/core) │ │ ├── linkerd-app v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app) (*) │ │ ├── linkerd-app-admin v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/admin) (*) │ │ ├── linkerd-app-gateway v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/gateway) (*) │ │ ├── linkerd-app-inbound v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/inbound) (*) │ │ ├── linkerd-app-integration v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/integration) │ │ ├── linkerd-app-outbound v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/outbound) (*) │ │ └── linkerd-app-test v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/test) │ │ ├── linkerd-app-inbound v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/inbound) (*) │ │ ├── linkerd-app-integration v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/integration) │ │ └── linkerd-app-outbound v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/outbound) (*) │ │ [dev-dependencies] │ │ ├── linkerd-app-gateway v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/gateway) (*) │ │ ├── linkerd-app-inbound v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/inbound) (*) │ │ └── linkerd-app-outbound v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/outbound) (*) │ ├── linkerd-app-inbound v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/inbound) (*) │ ├── linkerd-proxy-tap v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/proxy/tap) │ │ └── linkerd-app-core v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/core) (*) │ └── linkerd2-proxy v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd2-proxy) │ [dev-dependencies] │ ├── linkerd-app-inbound v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/inbound) (*) │ ├── linkerd-app-integration v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/integration) │ └── linkerd-app-outbound v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/outbound) (*) │ [dev-dependencies] │ ├── linkerd-app-inbound v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/inbound) (*) │ └── linkerd-app-outbound v0.1.0 (/home/eliza/Code/linkerd2-proxy/linkerd/app/outbound) (*) └── tokio-rustls v0.23.4 (*) ``` After: ```console $ cargo tree -p webpki -i error: package ID specification `webpki` did not match any packages ``` </details> [1]: https://github.com/linkerd/linkerd2-proxy/blob/8afc72258b8ced868fbd0bde0235955c0adf4ccd/Cargo.lock#L2450-L2460C2 [2]: #9299 (comment) --- 0e843c9f meshtls: update to `rustls` v0.21.7 (linkerd/linkerd2-proxy#2473) Signed-off-by: Eliza Weisman <[email protected]>

This branch cherry-picks #2472 onto `release/v2.203`. Currently, the proxy [depends on an outdated version of `rustls`][1], v0.20.8. The `rustls` dependency is via our dependency on `tokio-rustls` v0.23.4; we don't have a direct `rustls` dependency, in order to ensure that the version of `rustls` is always the same version as used by `tokio-rustls`. `rustls` also has a dependency on `webpki`, and v0.20.x of `rustls` uses the original `webpki` crate, rather than the `rustls-webpki` crate. So, unfortunately, because we have a transitive dep on `webpki` via `rustls`, PR linkerd/linkerd2-proxy#2465 did not remove _all_ `webpki` deps from our dependency tree, only the direct dependency. This branch updates to `rustls` v0.21.x, which depends on `rustls-webpki` rather than `webpki`, removing the `webpki` dependency. This is accomplished by updating `tokio-rustls` to v0.24.x, implicitly updating the transitive `rustls` dep. In order to update to the semver-incompatible version of `rustls`, it was necessary to modify our code in order to track some breaking API changes. I've also added a `cargo-deny` ban for `webpki` to our `deny.toml`, to ensure that we always use the actively-maintained `rustls-webpki` crate rather than `webpki` classic. Since peer certificate validation is performed through `rustls` rather than through the direct `rustls-webpki` dependency, this should hopefully resolve issues with issuer certs that contain name constraints --- these were not fixed by linkerd/linkerd2-proxy#2465, because the failure with certs containing name constraints occurred inside of the *`webpki` version depended on by `rustls`*, rather than inside of the proxy's direct dep. See [this comment][2] for details. In addition, it was necessary to update `rustls-webpki` to v0.101.6, since v0.101.5 was yanked due to an accidental API breaking change. [1]: https://github.com/linkerd/linkerd2-proxy/blob/8afc72258b8ced868fbd0bde0235955c0adf4ccd/Cargo.lock#L2450-L2460C2 [2]: #9299 (comment) --- 0e843c9f meshtls: update to `rustls` v0.21.7 (linkerd/linkerd2-proxy#2473) Signed-off-by: Eliza Weisman <[email protected]>

alpeb changed the title ~~Have the Webhook react to pod creation/update only~~ WIP: Have the Webhook react to pod creation/update only Mar 7, 2019

siggy assigned alpeb Mar 8, 2019

alpeb changed the title ~~WIP: Have the Webhook react to pod creation/update only~~ Have the Webhook react to pod creation/update only Mar 11, 2019

alpeb force-pushed the alpeb/webhook-pods branch from 7b3b5cb to 2ab8edd Compare March 11, 2019 21:42

alpeb marked this pull request as ready for review March 11, 2019 21:44

siggy added the priority/P0 Release Blocker label Mar 11, 2019

siggy reviewed Mar 11, 2019

View reviewed changes

siggy reviewed Mar 12, 2019

View reviewed changes

alpeb force-pushed the alpeb/webhook-pods branch from 497e284 to 687de9b Compare March 19, 2019 16:21

alpeb force-pushed the alpeb/webhook-pods branch from 687de9b to 967a8e1 Compare March 20, 2019 15:26

klingerf reviewed Mar 20, 2019

View reviewed changes

controller/proxy-injector/webhook.go Outdated Show resolved Hide resolved

chart/templates/proxy_injector.yaml Outdated Show resolved Hide resolved

pkg/k8s/labels.go Show resolved Hide resolved

ihcsim reviewed Mar 20, 2019

View reviewed changes

controller/proxy-injector/webhook.go Outdated Show resolved Hide resolved

alpeb force-pushed the alpeb/webhook-pods branch from 967a8e1 to 17c6f85 Compare March 22, 2019 20:19

alpeb added 5 commits March 25, 2019 10:33

Manually inject service account mount paths

62f4b52

Signed-off-by: Alejandro Pedraza <[email protected]>

Fix test and rebase

ae6f6b6

Signed-off-by: Alejandro Pedraza <[email protected]>

Rebase one more time

570f1bc

Signed-off-by: Alejandro Pedraza <[email protected]>

Address feedback and rebase

43edcab

Signed-off-by: Alejandro Pedraza <[email protected]>

alpeb force-pushed the alpeb/webhook-pods branch from 17c6f85 to 43edcab Compare March 25, 2019 15:53

ihcsim reviewed Mar 25, 2019

View reviewed changes

klingerf reviewed Mar 25, 2019

View reviewed changes

siggy reviewed Mar 25, 2019

View reviewed changes

controller/proxy-injector/webhook.go Outdated Show resolved Hide resolved

controller/proxy-injector/webhook.go Outdated Show resolved Hide resolved

pkg/inject/inject.go Outdated Show resolved Hide resolved

Address feedback

277f1bf

Signed-off-by: Alejandro Pedraza <[email protected]>

alpeb commented Mar 25, 2019

View reviewed changes

linkerd deleted a comment from l5d-bot Mar 25, 2019

siggy mentioned this pull request Mar 25, 2019

Add validation webhook for service profiles #2508

Closed

klingerf approved these changes Mar 26, 2019

View reviewed changes

cli/cmd/inject.go Outdated Show resolved Hide resolved

pkg/inject/inject.go Show resolved Hide resolved

pkg/inject/patch_test.go Show resolved Hide resolved

siggy approved these changes Mar 26, 2019

View reviewed changes

pkg/inject/inject.go Outdated Show resolved Hide resolved

Readd volumes tests

122bdb2

Signed-off-by: Alejandro Pedraza <[email protected]>

alpeb merged commit 7efe385 into master Mar 26, 2019

alpeb deleted the alpeb/webhook-pods branch March 26, 2019 16:54

alpeb mentioned this pull request Mar 26, 2019

Replace client.Corev1() calls with k8s.API calls in webhook.go #2566

Closed

ihcsim mentioned this pull request Mar 27, 2019

Consolidate Differences In Runtime YAML of Auto-Inject And Manual-Injected Workloads #2576

Closed

alpeb mentioned this pull request Mar 27, 2019

Update proxy-injector to support non-deployment workloads #1751

Closed

This was referenced Mar 28, 2019

Support Configs Override On Meshed Workloads #2498

Closed

2.3 - Docs for proxy configurations and first upgrade linkerd/website#236

Merged

hawkw mentioned this pull request Sep 25, 2023

proxy: v2.203.4 #11417

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Have the Webhook react to pod creation/update only #2472

Have the Webhook react to pod creation/update only #2472

alpeb commented Mar 7, 2019

alpeb commented Mar 11, 2019

siggy left a comment

olix0r commented Mar 11, 2019

alpeb commented Mar 12, 2019

siggy left a comment

alpeb commented Mar 12, 2019

alpeb commented Mar 19, 2019

klingerf left a comment

ihcsim left a comment

ihcsim commented Mar 20, 2019

alpeb commented Mar 20, 2019

ihcsim commented Mar 20, 2019

alpeb commented Mar 21, 2019

alpeb commented Mar 22, 2019

ihcsim left a comment

ihcsim Mar 25, 2019

alpeb Mar 25, 2019

ihcsim Mar 25, 2019

alpeb Mar 25, 2019

klingerf left a comment

siggy left a comment

alpeb Mar 25, 2019

alpeb Mar 25, 2019

klingerf left a comment

siggy left a comment

l5d-bot commented Mar 26, 2019

Have the Webhook react to pod creation/update only #2472

Have the Webhook react to pod creation/update only #2472

Conversation

alpeb commented Mar 7, 2019

alpeb commented Mar 11, 2019

siggy left a comment

Choose a reason for hiding this comment

steps to reproduce

this branch

master

olix0r commented Mar 11, 2019

alpeb commented Mar 12, 2019

siggy left a comment

Choose a reason for hiding this comment

alpeb commented Mar 12, 2019

alpeb commented Mar 19, 2019

klingerf left a comment

Choose a reason for hiding this comment

ihcsim left a comment

Choose a reason for hiding this comment

ihcsim commented Mar 20, 2019

alpeb commented Mar 20, 2019

ihcsim commented Mar 20, 2019

alpeb commented Mar 21, 2019

alpeb commented Mar 22, 2019

ihcsim left a comment

Choose a reason for hiding this comment

ihcsim Mar 25, 2019

Choose a reason for hiding this comment

alpeb Mar 25, 2019

Choose a reason for hiding this comment

ihcsim Mar 25, 2019

Choose a reason for hiding this comment

alpeb Mar 25, 2019

Choose a reason for hiding this comment

klingerf left a comment

Choose a reason for hiding this comment

siggy left a comment

Choose a reason for hiding this comment

alpeb Mar 25, 2019

Choose a reason for hiding this comment

alpeb Mar 25, 2019

Choose a reason for hiding this comment

klingerf left a comment

Choose a reason for hiding this comment

siggy left a comment

Choose a reason for hiding this comment

l5d-bot commented Mar 26, 2019