mirror of https://github.com/linkerd/linkerd2.git
147d85dc70
### What `GetProfile` clients do not receive destinatin profiles that consider Server protocol fields the way that `Get` clients do. If a Server exists for a `GetProfile` destination that specifies the protocol for that destination is `opaque`, this information is not passed back to the client. #7184 added this for `Get` by subscribing clients to Endpoint/EndpointSlice updates. When there is an update, or there is a Server update, the endpoints watcher passes this information back to the endpoint translator which handles sending the update back to the client. For `GetProfile` the situation is different. As with `Get`, we only consider Servers when dealing with Pod IPs, but this only occurs in two situations for `GetProfile`. 1. The destination is a Pod IP and port 2. The destionation is an Instance ID and port In both of these cases, we need to check if a already Server selects the endpoint and we need to subscribe for Server updates incase one is added or deleted which selects the endpoint. ### How First we check if there is already a Server which selects the endpoint. This is so that when the first destionation profile is returned, the client knows if the destination is `opaque` or not. After sending that first update, we then subscribe the client for any future updates which will come from a Server being added or deleted. This is handled by the new `ServerWatcher` which watches for Server updates on the cluster; when an update occurs it sends that to the `endpointProfileTranslator` which translates the protcol update into a DestinationProfile. By introducing the `endpointProfileTranslator` which only handles protocol updates, we're able to decouple the endpoint logic from `profileTranslator`—it's `endpoint` field has been removed now that it only handles updates for ServiceProfiles for Services. ### Testing A unit test has been added and below are some manual testing instructions to see how it interacts with Server updates: <details> <summary>app.yaml</summary> ```yaml apiVersion: v1 kind: Pod metadata: name: pod labels: app: pod spec: containers: - name: app image: nginx ports: - name: http containerPort: 80 --- apiVersion: policy.linkerd.io/v1beta1 kind: Server metadata: name: srv labels: policy: srv spec: podSelector: matchLabels: app: pod port: 80 proxyProtocol: opaque ``` </details> ```shell $ go run ./controller/cmd/main.go destination ``` ```shell $ linkerd inject app.yaml |kubectl apply -f - ... $ kubectl get pods -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES pod 2/2 Running 0 53m 10.42.0.34 k3d-k3s-default-server-0 <none> <none> $ go run ./controller/script/destination-client/main.go -method getProfile -path 10.42.0.34:80 ... ``` You can add/delete `srv` as well as edit its `proxyProtocol` field to observe the correct DestinationProfile updates. Signed-off-by: Kevin Leimkuhler <kleimkuhler@icloud.com> |
||
|---|---|---|
| .. | ||
| destination | ||
| util | ||