mirror k8s probe dialers

fix istioctl build

fix istioctl build

/retest

lint

mirror k8s probe dialers

Please provide a description of this PR: Fixes https://github.com/istio/istio/issues/42979

To help us figure out who should review this PR, please put an X in all the areas that this PR affects.

• [ ] Ambient
• [ ] Configuration Infrastructure
• [ ] Docs
• [ ] Installation
• [x] Networking
• [ ] Performance and Scalability
• [ ] Policies and Telemetry
• [ ] Security
• [ ] Test and Release
• [ ] User Experience
• [ ] Developer Infrastructure

Please check any characteristics that apply to this pull request.

• [x] Does not have any user-facing changes. This may include CLI changes, API changes, behavior changes, performance improvements, etc.

mirror k8s probe dialers

Change hardcoded values to util variables (#42427)

Automator: update common-files@master in istio/istio@master (#42440)

Automator: update common-files@master in istio/istio@master (#42445)

istioctl: fix istioctl operator remove fail when a revision was not specified (#42160)

Signed-off-by: xin.li xin.li@daocloud.io

Signed-off-by: xin.li xin.li@daocloud.io

Automator: update istio/pkg@master dependency in istio/istio@master (#42446)

Automator: update proxy@master in istio/istio@master (#42447)

Automator: update istio/client-go@master dependency in istio/istio@master (#42442)

gateway-api: support InvalidTLSConfiguration (#42113)

• support MissingReferencedSecret

• support malformed certificates

• fix lint

• add update func

• use credentials controller

Bump helm.sh/helm/v3 from 3.10.2 to 3.10.3 (#42454)

Bumps helm.sh/helm/v3 from 3.10.2 to 3.10.3.

• Release notes
• Commits

updated-dependencies:

• dependency-name: helm.sh/helm/v3 dependency-type: direct:production ...

Signed-off-by: dependabot[bot] support@github.com

Signed-off-by: dependabot[bot] support@github.com Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

Automator: update proxy@master in istio/istio@master (#42455)

Auto-name the VS routes in HTTPRoute auto-generated (#42456)

• Name the route

• Add namespace to be sure

• Update golden files with the names

improve metav1 package statement (#42287)

Signed-off-by: xin.li xin.li@daocloud.io

Signed-off-by: xin.li xin.li@daocloud.io

Automator: update istio/client-go@master dependency in istio/istio@master (#42461)

Fix locality label missing (#42412)

• Fix locality label missing

• fix

• Add test for locality label

• refresh golden file

• lint

• address comment

• add release note

• defer restore wd

Automator: update istio/client-go@master dependency in istio/istio@master (#42462)

Automator: update common-files@master in istio/istio@master (#42468)

Automator: update istio/client-go@master dependency in istio/istio@master (#42469)

Update go-control-plane (#42466)

Automator: update proxy@master in istio/istio@master (#42478)

Automator: update istio/pkg@master dependency in istio/istio@master (#42473)

When i'm deploying GW + VS I get the same issue oddly enough, obviously i first recreate the kind cluster, then:

You should specify the namespace in VS.spec.gateways

  gateways:
  - istio-ingress/ig-gateway

I am fairly sure this is not safe... Per the comments in the code its only safe when we are not pushing CDS changes.

Example breakage:

• Debounce is DR=foo.com,Svc=bar.com
• We now will do a partial push to bar.com CLA only
• Broken?

I don't get it, DR is not in skippedEdsConfigs, so we will send a full push, why is that broken?

rename

add comments

Besides Endpoint and EndpointSlice - doesn't everything potentially generate CDS or RDS/LDS changes ? ServiceEntry also has at least 'alternateServiceNames' and possibly few others that impact CDS. WorkloadEntry may also be safe. I think we need some very detailed comments explaining what is the intent and why any change can lead to a safe 'EDS only' push.

I don't think this will impact other xDS workflow. This PR has nothing to do with "EDS only", but just push the ClusterLoadAssignments that are actually changed

For example:

• Service updated -> incremental EDS push
• VirtualService updated -> no EDS push

But when debounce kicks in:

• Service and VirtualService updated -> full EDS push

I expect it should also push increments which I think is fairly safe?

Please provide a description of this PR: When checking incremental EDS, we can ignore irrelevant resource updates merged by debounce. This happens in cases like creating a VS right after a service, which is a common practice I think

To help us figure out who should review this PR, please put an X in all the areas that this PR affects.

• [ ] Ambient
• [ ] Configuration Infrastructure
• [ ] Docs
• [ ] Installation
• [x] Networking
• [ ] Performance and Scalability
• [ ] Policies and Telemetry
• [ ] Security
• [ ] Test and Release
• [ ] User Experience
• [ ] Developer Infrastructure

Please check any characteristics that apply to this pull request.

• [x] Does not have any user-facing changes. This may include CLI changes, API changes, behavior changes, performance improvements, etc.