diff --git a/docs/extensions/cluster.md b/docs/extensions/cluster.md index 2c536f0bd17..24ae15925aa 100644 --- a/docs/extensions/cluster.md +++ b/docs/extensions/cluster.md @@ -1,7 +1,7 @@ # `Cluster` resource As part of the extensibility epic a lot of responsibility that was previously taken over by Gardener directly has now been shifted to extension controllers running in the seed clusters. -These extensions often serve a well-defined purpose, e.g. the management of [DNS records](dns.md), [infrastructure](infrastructure.md), etc. +These extensions often serve a well-defined purpose, e.g. the management of [DNS records](dnsrecord.md), [infrastructure](infrastructure.md), etc. We have introduced a couple of extension CRDs in the seeds whose specification is written by Gardener, and which are acted up by the extensions. However, the extensions sometimes require more information that is not directly part of the specification. diff --git a/docs/extensions/dnsrecord.md b/docs/extensions/dnsrecord.md index 3d43757fd00..96969778f53 100644 --- a/docs/extensions/dnsrecord.md +++ b/docs/extensions/dnsrecord.md @@ -7,7 +7,7 @@ title: DNS Record Every shoot cluster requires external DNS records that are publicly resolvable. The management of these DNS records requires provider-specific knowledge which is to be developed outside the Gardener's core repository. -Currently, Gardener uses [`DNSProvider` and `DNSEntry` resources](dns.md). However, this introduces undesired coupling of Gardener to a controller that does not adhere to the Gardener extension contracts. Because of this, we plan to stop using `DNSProvider` and `DNSEntry` resources for Gardener DNS records in the future and use the `DNSRecord` resources described here instead. +Currently, Gardener uses `DNSProvider` and `DNSEntry` resources. However, this introduces undesired coupling of Gardener to a controller that does not adhere to the Gardener extension contracts. Because of this, we plan to stop using `DNSProvider` and `DNSEntry` resources for Gardener DNS records in the future and use the `DNSRecord` resources described here instead. ## What does Gardener create DNS records for? diff --git a/docs/proposals/13-automated-seed-management.md b/docs/proposals/13-automated-seed-management.md index 19f80a1e29c..ce7d19e0cd8 100644 --- a/docs/proposals/13-automated-seed-management.md +++ b/docs/proposals/13-automated-seed-management.md @@ -75,7 +75,7 @@ Later, the scheduling algorithm could be further enhanced by replacing the step ## ManagedSeeds -When all or most of the existing seeds are near capacity, new seeds should be created in order to accommodate more shoots. Conversely, sometimes there could be too many seeds for the number of shoots, and so some of the seeds could be deleted to save resources. Currently, the process of creating a new seed involves a number of manual steps, such as creating a new shoot that meets certain criteria, and then registering it as a seed in Gardener. This could be automated to some extent by [annotating a shoot with the `use-as-seed` annotation](../usage/shooted_seed.md), in order to create a "shooted seed". However, adding more than one similar seeds still requires manually creating all needed shoots, annotating them appropriately, and making sure that they are successfully reconciled and registered. +When all or most of the existing seeds are near capacity, new seeds should be created in order to accommodate more shoots. Conversely, sometimes there could be too many seeds for the number of shoots, and so some of the seeds could be deleted to save resources. Currently, the process of creating a new seed involves a number of manual steps, such as creating a new shoot that meets certain criteria, and then registering it as a seed in Gardener. This could be automated to some extent by annotating a shoot with the `use-as-seed` annotation, in order to create a "shooted seed". However, adding more than one similar seeds still requires manually creating all needed shoots, annotating them appropriately, and making sure that they are successfully reconciled and registered. To create, delete, and update seeds effectively in a declarative way and allow auto-scaling, a "creatable seed" resource along with a "set" (and in the future, perhaps also a "deployment") of such creatable seeds should be introduced, similar to Kubernetes `Pod`, `ReplicaSet`, and `Deployment` (or to MCM `Machine`, `MachineSet`, and `MachineDeployment`) resources. With such resources (and their respective controllers), creating a new seed based on a template would become as simple as increasing the `replicas` field in the "set" resource. diff --git a/docs/proposals/19-migrating-to-prometheus-operator.md b/docs/proposals/19-migrating-to-prometheus-operator.md index fc1e7c10789..b5b76820b35 100644 --- a/docs/proposals/19-migrating-to-prometheus-operator.md +++ b/docs/proposals/19-migrating-to-prometheus-operator.md @@ -17,19 +17,21 @@ reviewers: ## Table of Contents -- [Summary](#summary) -- [Motivation](#motivation) - - [Goals](#goals) - - [Non-Goals](#non-goals) -- [Proposal](#proposal) - - [API](#api) - - [Prometheus-Operator-CRDs](#prometheus-operator-crds) - - [Shoot-Monitoring](#shoot-monitoring) - - [Seed-Monitoring](#seed-monitoring) - - [BYOMC](#byomc-bring-your-own-monitoring-configuration) - - [Grafana-Sidecar](#grafana-sidecar) - - [Migration](#migration) -- [Alternatives](#alternatives) +- [GEP-19: Monitoring Stack - Migrating to the prometheus-operator](#gep-19-monitoring-stack---migrating-to-the-prometheus-operator) + - [Table of Contents](#table-of-contents) + - [Summary](#summary) + - [Motivation](#motivation) + - [Goals](#goals) + - [Non-Goals](#non-goals) + - [Proposal](#proposal) + - [API](#api) + - [Prometheus Operator CRDs](#prometheus-operator-crds) + - [Shoot Monitoring](#shoot-monitoring) + - [Seed Monitoring](#seed-monitoring) + - [BYOMC (Bring your own monitoring configuration)](#byomc-bring-your-own-monitoring-configuration) + - [Grafana Sidecar](#grafana-sidecar) + - [Migration](#migration) + - [Alternatives](#alternatives) ## Summary @@ -517,7 +519,6 @@ Add a [sidecar][grafana-sidecar] to Grafana that will pickup dashboards and prov [prom-op-issue]: https://github.com/prometheus-operator/prometheus-operator/issues/4828 [prometheus-operator]: https://github.com/prometheus-operator/prometheus-operator [seed-alertmanager]: https://github.com/gardener/gardener/blob/0f4d22270927e2aee8b821f858fb76162ccd8a86/charts/seed-bootstrap/templates/alertmanager/alertmanager.yaml -[seed-bootstrap]: https://github.com/gardener/gardener/tree/master/charts/seed-bootstrap/charts/kube-state-metrics [shoot-alertmanager]: https://github.com/gardener/gardener/tree/master/charts/seed-monitoring/charts/alertmanager [shoot-monitoring]: https://github.com/gardener/gardener/tree/master/charts/seed-monitoring/charts [sidecar-configuration]: https://github.com/kiwigrid/k8s-sidecar#configuration-environment-variables diff --git a/docs/proposals/20-ha-control-planes.md b/docs/proposals/20-ha-control-planes.md index 73af6b105cf..187449522fc 100644 --- a/docs/proposals/20-ha-control-planes.md +++ b/docs/proposals/20-ha-control-planes.md @@ -1023,9 +1023,9 @@ $ etcdctl endpoint status --cluster -w table | ENDPOINT | ID | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | |------------------------------------------------------------------------|------------------|---------|---------|-----------|------------|-----------|------------|--------------------| -| https://etcd-main-0.etcd-main-peer.shoot--ash-garden--mz-neem.svc:2379 | 37e93e9d1dd2cc8e | 3.4.13 | 7.6 MB | false | false | 47 | 3863 | 3863 | -| https://etcd-main-2.etcd-main-peer.shoot--ash-garden--mz-neem.svc:2379 | 65fe447d73e9dc58 | 3.4.13 | 7.6 MB | true | false | 47 | 3863 | 3863 | -| https://etcd-main-1.etcd-main-peer.shoot--ash-garden--mz-neem.svc:2379 | ad4fe89f4e731298 | 3.4.13 | 7.6 MB | false | false | 47 | 3863 | 3863 | +| `https://etcd-main-0.etcd-main-peer.shoot--ash-garden--mz-neem.svc:2379` | 37e93e9d1dd2cc8e | 3.4.13 | 7.6 MB | false | false | 47 | 3863 | 3863 | +| `https://etcd-main-2.etcd-main-peer.shoot--ash-garden--mz-neem.svc:2379` | 65fe447d73e9dc58 | 3.4.13 | 7.6 MB | true | false | 47 | 3863 | 3863 | +| `https://etcd-main-1.etcd-main-peer.shoot--ash-garden--mz-neem.svc:2379` | ad4fe89f4e731298 | 3.4.13 | 7.6 MB | false | false | 47 | 3863 | 3863 |
Multi-zonal shoot control plane ingress/egress traffic in a fresh shoot cluster with no user activity diff --git a/docs/usage/dns-search-path-optimization.md b/docs/usage/dns-search-path-optimization.md index 5fe80e409f6..bcad942722b 100644 --- a/docs/usage/dns-search-path-optimization.md +++ b/docs/usage/dns-search-path-optimization.md @@ -64,7 +64,7 @@ trailing dot (`.`). Furthermore, it makes moving to different landscapes more di ## Gardener specific Workarounds/Mitigations -Gardener allows users to [customize their DNS configuration](custom-dns.md). CoreDNS allows several approaches to deal with +Gardener allows users to [customize their DNS configuration](custom-dns-config.md). CoreDNS allows several approaches to deal with the requests generated by the DNS search path. [Caching](https://coredns.io/plugins/cache/) is possible as well as [query rewriting](https://coredns.io/plugins/rewrite/). There are also several other [plugins](https://coredns.io/plugins/) available, which may mitigate the situation.