Rebrand to Welkin in configuration documentation

[cristiklein]

[!warning] This is a public repository, ensure not to disclose:

• [x] personal data beyond what is necessary for interacting with this pull request, nor
• [x] business confidential information, such as customer names.

What kind of PR is this?

Required: Mark one of the following that is applicable:

• [ ] kind/feature
• [ ] kind/improvement
• [ ] kind/deprecation
• [x] kind/documentation
• [ ] kind/clean-up
• [ ] kind/bug
• [ ] kind/other

Optional: Mark one or more of the following that are applicable:

[!important] Breaking changes should be marked kind/admin-change or kind/dev-change depending on type Critical security fixes should be marked with kind/security

• [ ] kind/admin-change
• [ ] kind/dev-change
• [ ] kind/security
• [ ] [kind/adr]()

What does this PR do / why do we need this PR?

The https://elastisys.io website was recently rebranded to Welkin. Some part of that website are generated from Apps configuration documentation. Therefore this PR rebrands those part of Apps which end up on https://elastisys.io.

Note that, rebranding the source code is out-of-scope of that migration project and is a decision-to-be-taken.

• Part of an internal issue

Information to reviewers

Checklist

• [x] Proper commit message prefix on all commits
• Change checks:
  • [x] The change is transparent
  • [ ] The change is disruptive
  • [ ] The change requires no migration steps
  • [ ] The change requires migration steps
  • [ ] The change upgrades CRDs
  • [ ] The change updates the config and the schema
• Documentation checks:
  • [x] The public documentation required no updates
  • [ ] The public documentation required an update - link to change
• Metrics checks:
  • [ ] The metrics are still exposed and present in Grafana after the change
  • [ ] The metrics names didn't change (Grafana dashboards and Prometheus alerts are not affected)
  • [ ] The metrics names did change (Grafana dashboards and Prometheus alerts were fixed)
• Logs checks:
  • [ ] The logs do not show any errors after the change
• Pod Security Policy checks:
  • [ ] Any changed pod is covered by Pod Security Admission
  • [ ] Any changed pod is covered by Gatekeeper Pod Security Policies
  • [ ] The change does not cause any pods to be blocked by Pod Security Admission or Policies
• Network Policy checks:
  • [ ] Any changed pod is covered by Network Policies
  • [ ] The change does not cause any dropped packets in the NetworkPolicy Dashboard
• Audit checks:
  • [ ] The change does not cause any unnecessary Kubernetes audit events
  • [ ] The change requires changes to Kubernetes audit policy
• Falco checks:
  • [ ] The change does not cause any alerts to be generated by Falco
• Bug checks:
  • [ ] The bug fix is covered by regression tests

[lunkan93]

I saw that there are still a few uses of ck8s in the schema, should those perhaps also be changed?

[cristiklein]

I saw that there are still a few uses of ck8s in the schema, should those perhaps also be changed?

Good point! I only found one instance of ck8s in prose. When and how to change code (which includes config key changes) is out-of-scope for this migration and needs to be determined later.

[lunkan93]

I saw that there are still a few uses of ck8s in the schema, should those perhaps also be changed?

Good point! I only found one instance of ck8s in prose. When and how to change code (which includes config key changes) is out-of-scope for this migration and needs to be determined later.

Maybe this example too? Otherwise LGTM

[cristiklein]

I saw that there are still a few uses of ck8s in the schema, should those perhaps also be changed?

Good point! I only found one instance of ck8s in prose. When and how to change code (which includes config key changes) is out-of-scope for this migration and needs to be determined later.

Maybe this example too? Otherwise LGTM

Thanks for catching this too! Didn't realize that changing example values is safe too.