Hi @matzew. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

<details>

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. </details>

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: <a href="https://github.com/kubernetes-sigs/kind/pull/2307#" title="Author self-approved">matzew</a> To complete the pull request process, please assign amwat after the PR has been reviewed. You can assign the PR to them by writing /assign @amwat in a comment when ready.

The full list of commands accepted by this bot can be found here.

<details open> Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment </details> <!-- META={"approvers":["amwat"]} -->

Pointing to 0.11.1 as the latest / stable version

Signed-off-by: yiyiyimu [email protected]

fix #92, reopened from #99

cc @tao12345666333

• install apisix only https://github.com/apache/apisix-helm-chart/blob/605c0c5520fe2b9b7724df3269b5471f14d88db4/charts/apisix/values.yaml#L215-L220 It seems by default install apisix would not install dashboard and ingress controller together, but when following the guidance, it still installs all three componenents. Tried to override with helm install apisix apisix/apisix --set dashboard.enabled=false --set ingress-controller.enabled=false but still failed.

• install etcd cluster I think it's recommended to install a three-nodes etcd cluster rather than one. Besides, I'm not sure and also failed to find how to passing subchart parameters.

Hi @tao12345666333 could you help me on this

Having Environment-Variable based Flags without an corresponding CLI flag is no good UX, in my opinion. So I would consider implementing the --address-type flag, as discussed in #2217.

From https://github.com/kubernetes-sigs/kind/issues/2217#issuecomment-832530967:

My suggestion for --address-type would be:

-address-type=	URL	Host-Resolvable	Container-Resolvable
container-name	https://kind-control-plane:6443	No	Yes
container-ip	https://172.18.0.2:6443	Linux only	Yes, on 'kind' network
host-port	https://127.0.0.1:36995	Yes	No

The current default would be "host-port". I would use "container-ip" as the default on Linux, because the URL is resolvable on the host, and internally.

A clean migration path could be like:

• Phase 1: Quit with error if one uses --internal and --address-type
• Phase 1: Output a descriptive warning to stderr if --internal is used, and continue with --address-type=container-name
• Phase 2: Remove --internal from help, and quit with a descriptive error if it is still used
• Phase 3: Remove --internal completely, if it is still used one will just get an "invalid flag" generic error

/remove-lifecycle stale

We would have to create a new config since we do not have any presubmits for k/sig-release right now. There are different images available for different purposes. For example we maintain a gcr.io/k8s-staging-releng/releng-ci:latest-go1.16 image in k/release, where I could imagine that we add required tools to this one.

It seems odd to have the TAGs have zero involvement in the Graduation process. Shouldn't they review the application and comment, or something?

I agree. The current graduation docs do specify that the TAGs may weigh in at the same time as end users during step 2 of the graduation process, but it may be worth at least a cursory check with the TAG before the initial private review to follow up with the project. They may know about potential issues that should be addressed that are not known to the TOC.

Initial review in private, TOC sponsor volunteers at that point, feedback to project in the pull request.

A few small asks with this:

• Establish a timeframe for review, e.g. within 1 month, to not leave a project requesting review with an indeterminate amount of time before receiving feedback on the PR.
• codify TOC volunteer in a similar way to the TOC Incubation Sponsor in Step 2 of the graduation process (can't link directly to the step -_-)

TOC reviews in a public meeting (2 a year scheduled) and provides feedback

This seems like quite a long period between sessions to provide feedback, is there a reason for this vs adhoc like incubation? Ideally the incubation -> graduation phase should have less DD with more of the work being put at the sandbox -> graduation phase.

I'm not a contributor to Falco, but was a heavy end user in my previous role. They've done a great job with building a community around the project 👍

It's been a little over a month since the last update, but it looks like there has been a good amount of progress towards reducing references:

For the various references to sysdig in the codebase, I did a quick look:

• There are 244 remaining references, 146 if you omit the archived repos.
• Of those, 24 are references in the falcosecurity/libs repo.
• 16 in Falco's primary repo, with a few being changelog items etc.
• Theres still about the same amount in the website repo, but a good chunk of those are blog posts or localizations of content.

If there are concerns about still having a high number of references from the archived projects in the main project org, one potential idea might be to mimic the archive org pattern e.g. kubernetes-retired and move the repos there which can act as a very clear signal to users about the state of those projects.

I'm facing the very same issue in my deployment. It started after I install kind v.0.10.0 and node kindest/node:v1.18.15.

I've never had problems with v0.9.0 and node kindest/node:v1.18.8

I noticed that containerd version of both kindest/node:v1.18.15 and my local kindest/node@sha256:8f7ea6e7642c0da54f(its tag is v1.20.2, but inconsistent with upstream v1.20.2):

# docker run --privileged --entrypoint /usr/local/bin/containerd -it kindest/node@sha256:8f7ea6e7642c0da54f04a7ee10431549c0257315b3a634f6ef2fecaaedb19bab --version
containerd github.com/containerd/containerd v1.4.0-106-gce4439a8 ce4439a8151f77dc50adb655ab4852ee9c366589

# docker run  --privileged --entrypoint /usr/local/bin/containerd -it kindest/node:v1.18.15   --version
containerd github.com/containerd/containerd v1.4.0-106-gce4439a8 ce4439a8151f77dc50adb655ab4852ee9c366589

# docker run  --privileged --entrypoint /usr/local/bin/containerd -it kindest/node:v1.18.8   --version
containerd github.com/containerd/containerd v1.4.0 09814d48d50816305a8e6c1a4ae3e2bcc4ba725a

v1.4.0-106-gce4439a8 at here: https://github.com/kind-ci/containerd-nightlies/releases/tag/containerd-1.4.0-106-gce4439a8

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-contributor-experience at kubernetes/community. /lifecycle stale

we discussed this some time ago, the problem is that this we are always going to break someone ingress/v1 is 1.19 IIRC, it won't work for previous versions ingress/v1beta1 will stop to work since 1.22 :shrug:

Hi @juniorjbn. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

<details>

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. </details>

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: <a href="https://github.com/kubernetes-sigs/kind/pull/2306#" title="Author self-approved">juniorjbn</a> To complete the pull request process, please assign bentheelder after the PR has been reviewed. You can assign the PR to them by writing /assign @bentheelder in a comment when ready.

The full list of commands accepted by this bot can be found here.

<details open> Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment </details> <!-- META={"approvers":["bentheelder"]} -->

Update ingress from v1bet1 to v1 and update Ingress.spec.rules[0].http.paths[0].backend changes. https://kubernetes.io/docs/concepts/services-networking/ingress/

Update ingress apiVersion from v1beta1 to v1 to fix this warning: Warning: networking.k8s.io/v1beta1 Ingress is deprecated in v1.19+, unavailable in v1.22+; use networking.k8s.io/v1 Ingress

Hi @juniorjbn. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

<details>

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. </details>

Welcome @juniorjbn! <br><br>It looks like this is your first PR to <a href='https://github.com/kubernetes-sigs/kind'>kubernetes-sigs/kind</a> 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval. <br><br>You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation. <br><br>You can also check if kubernetes-sigs/kind has its own contribution guidelines. <br><br>You may want to refer to our testing guide if you run into trouble with your tests not passing. <br><br>If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs! <br><br>Thank you, and welcome to Kubernetes. :smiley:

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: <a href="https://github.com/kubernetes-sigs/kind/pull/2305#" title="Author self-approved">juniorjbn</a> To complete the pull request process, please assign munnerz after the PR has been reviewed. You can assign the PR to them by writing /assign @munnerz in a comment when ready.

The full list of commands accepted by this bot can be found here.

<details open> Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment Approvers can cancel approval by writing /approve cancel in a comment </details> <!-- META={"approvers":["munnerz"]} -->

Update ingress apiVersion from v1beta1 to v1 to fix this warning: Warning: networking.k8s.io/v1beta1 Ingress is deprecated in v1.19+, unavailable in v1.22+; use networking.k8s.io/v1 Ingress