Kyma Istio Operator labels namespace for sidecar injection

[strekm]

Description

With high demand for workloads being part of Istio Service Mesh, Kyma Istio Operator should be responsible for labeling namespaces with sidecar injection enabled. Istio default setting for automatic sidecar injection is false. From previous experiences with this configuration proving it's hard in maintenance and error prone. This setting should stay as in default Istio. Instead Kyma Istio Operator should label namespaces with sidecar injection enabled.

Istio CR should have configuration option for auto sidecar injection for namespaces. By default this should be true. All namespaces except kube-system or those already labeled should be labeled with sidecar injection true.

ACs:

• [ ] Istio CR updated
• [ ] Istio CR UI adjusted
• [ ] docu updated
• [ ] integration test exists

Reasons

All workloads in namespaces are automatically part of service mesh

DoD:

• [ ] provide documentation
• [ ] release notes and What's New updates for Kyma customers
• [ ] provide unit tests
• [ ] provide integration tests
• [ ] test on production-like environment - [ ] verify resource limits - [ ] followup issue
• [ ] PR reviewer will verify code coverage and evaluate if it is acceptable

Attachments

[kyma-bot]

This issue or PR has been automatically marked as stale due to the lack of recent activity. Thank you for your contributions.

This bot triages issues and PRs according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 7d of inactivity since lifecycle/stale was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Close this issue or PR with /close

If you think that I work incorrectly, kindly raise an issue with the problem.

/lifecycle stale

[kyma-bot]

This issue or PR has been automatically closed due to the lack of activity. Thank you for your contributions.

This bot triages issues and PRs according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 7d of inactivity since lifecycle/stale was applied, the issue is closed

You can:

• Reopen this issue or PR with /reopen
• Mark this issue or PR as fresh with /remove-lifecycle stale

If you think that I work incorrectly, kindly raise an issue with the problem.

/close

[kyma-bot]

@kyma-bot: Closing this issue.

In response to [this](https://github.com/kyma-project/istio/issues/361#issuecomment-1798338474): >This issue or PR has been automatically closed due to the lack of activity. >Thank you for your contributions. > >This bot triages issues and PRs according to the following rules: >- After 60d of inactivity, `lifecycle/stale` is applied >- After 7d of inactivity since `lifecycle/stale` was applied, the issue is closed > >You can: >- Reopen this issue or PR with `/reopen` >- Mark this issue or PR as fresh with `/remove-lifecycle stale` > >If you think that I work incorrectly, kindly [raise an issue](https://github.com/kyma-project/test-infra/issues/new/choose) with the problem. > >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.

[kyma-bot]

This issue or PR has been automatically marked as stale due to the lack of recent activity. Thank you for your contributions.

This bot triages issues and PRs according to the following rules:

• After 60d of inactivity, lifecycle/stale is applied
• After 7d of inactivity since lifecycle/stale was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Close this issue or PR with /close

If you think that I work incorrectly, kindly raise an issue with the problem.

/lifecycle stale