fix(docs): Fixing typos in docs and comments (#5995)

Author: thetillhoff

docs/20190708-external-dns-incubator.md

@@ -18,7 +18,7 @@
 
 [ExternalDNS](https://github.com/kubernetes-sigs/external-dns) is a project that synchronizes Kubernetes' Services, Ingresses and other Kubernetes resources to DNS backends for several DNS providers.
 
-The projects was started as a Kubernetes Incubator project in February 2017 and being the Kubernetes incubation initiative officially over, the maintainers want to propose the project to be moved to the kubernetes GitHub organization or to kubernetes-sigs, under the sponsorship of sig-network.
+The project was started as a Kubernetes Incubator project in February 2017 and being the Kubernetes incubation initiative officially over, the maintainers want to propose the project to be moved to the kubernetes GitHub organization or to kubernetes-sigs, under the sponsorship of sig-network.
 
 ## Motivation
 
@@ -62,7 +62,7 @@ Given that the kubernetes-sigs organization will eventually be shut down, the po
 
 - Move the project elsewhere
 
-We believe that those alternatives would result in a worse outcome for the community compared to moving the project to the any of the other official Kubernetes organizations.
+We believe that those alternatives would result in a worse outcome for the community compared to moving the project to any of the other official Kubernetes organizations.
 In fact, shutting down ExternalDNS can cause:
 
 - The community to rebuild the same solution as already happened multiple times before the project was launched. Currently ExternalDNS is easy to be found, referenced in many articles/tutorials and for that reason not exposed to that risk.
@@ -89,7 +89,7 @@ We have evidence that many companies are using ExternalDNS in production, but it
 
 The project was quoted by a number of tutorials on the web, including the [official tutorials from AWS](https://aws.amazon.com/blogs/opensource/unified-service-discovery-ecs-kubernetes/).
 
-ExternalDNS can't be consider to be "done": while the core functionality has been implemented, there is lack of integration testing and structural changes that are needed.
+ExternalDNS can't be considered to be "done": while the core functionality has been implemented, there is lack of integration testing and structural changes that are needed.
 
 Those are identified in the project roadmap, which is roughly made of the following items:
 
@@ -132,7 +132,7 @@ The release pipeline for the project is currently fully owned by Zalando. It run
 
 The docker registry service is provided as best effort with no sort of SLA and the maintainers team openly suggests the users to build and maintain their own docker image based on the provided Dockerfiles.
 
-Providing a vanity URL for the docker images was consider a non goal till now, but the community seems to be wanting official images from a GCR domain, similarly to what is available for other parts of official Kubernetes projects.
+Providing a vanity URL for the docker images was considered a non goal till now, but the community seems to be wanting official images from a GCR domain, similarly to what is available for other parts of official Kubernetes projects.
 
 ExternalDNS does not follow a specific release cycle. Releases are made often when there are major contributions (i.e. new providers) or important bug fixes. That said, the default branch is considered stable and can be used as well to build images.
 

docs/advanced/configuration-precedence.md

@@ -37,7 +37,7 @@ flowchart TD
 
 3. **Environment Variables**
    - May override defaults, and in some cases may take precedence over CLI flags and annotations.
-   - Behavior depends on how the variable is mapped in the code. Where or not it replicates CLI flag or provider specific. Example: `kubectl` or `cloudflare`.
+   - Behavior depends on how the variable is mapped in the code. Whether or not it replicates CLI flag or provider specific. Example: `kubectl` or `cloudflare`.
 
 4. **Defaults**
    - If none of the above specify a value, ExternalDNS falls back to its defaults.

docs/advanced/fqdn-templating.md

@@ -241,7 +241,7 @@ This is helpful in scenarios such as:
 - You must still ensure the resulting FQDN is valid and unique.
 - Since Go templates can be error-prone, test your template with simple examples before deploying. Mismatched field names or nil values (e.g., missing labels) will result in errors or skipped entries.
 
-## FaQ
+## FAQ
 
 ### Can I specify multiple global FQDN templates?
 

docs/contributing/design.md

@@ -19,7 +19,7 @@ You can pick which `Source` and `Provider` to use at runtime via the `--source`
 
 ## Adding a DNS Provider
 
-A typical way to start on, e.g. a CoreDNS provider, would be to add a `coredns.go` to the providers package and implement the interface methods. Then you would have to register your provider under a name in `main.go`, e.g. `coredns`, and would be able to trigger it's functions via setting `--provider=coredns`.
+A typical way to start on, e.g. a CoreDNS provider, would be to add a `coredns.go` to the providers package and implement the interface methods. Then you would have to register your provider under a name in `main.go`, e.g. `coredns`, and would be able to trigger its functions via setting `--provider=coredns`.
 
 Note, how your provider doesn't need to know anything about where the DNS records come from, nor does it have to figure out the difference between the current and the desired state, it merely executes the actions calculated by the plan.
 

docs/contributing/dev-guide.md

@@ -18,7 +18,7 @@ Building and/or testing `external-dns` requires additional tooling.
 
 ## First Steps
 
-***Configure Development Environment**
+***Configure Development Environment***
 
 You must have a working [Go environment](https://go.dev/doc/install), compile the build, and set up testing.
 
@@ -154,7 +154,7 @@ When building local images with ko you can't specify the registry used to create
 ❯❯ export KO_DOCKER_REPO=ko.local
 ❯❯ export VERSION=v1
 ❯❯ docker context use rancher-desktop ## (optional) this command is only required when using rancher-desktop
-❯❯ ls -al /var/run/docker.sock ## (optional) validate tha docker runtime is configured correctly and symlink exist
+❯❯ ls -al /var/run/docker.sock ## (optional) validate that docker runtime is configured correctly and symlink exists
 
 ❯❯ ko build --tags ${VERSION}
 ❯❯ docker images
@@ -275,7 +275,7 @@ This helm chart comes with a JSON schema generated from values with [helm schema
 ❯❯ scripts/helm-tools.sh --docs
 ```
 
-6. Run helm unittets.
+6. Run helm unittests.
 
 ```sh
 ❯❯ make helm-test

docs/faq.md

@@ -168,7 +168,7 @@ Under certain circumstances you want to force ExternalDNS to create CNAME record
 Why should I want to force ExternalDNS to create CNAME records for ELB/ALB? Some motivations of users were:
 
 > "Our hosted zones records are synchronized with our enterprise DNS. The record type ALIAS is an AWS proprietary record type and AWS allows you to set a DNS record directly on AWS resources.
-> Since this is not a DNS RfC standard and therefore can not be transferred and created in our enterprise DNS. So we need to force CNAME creation instead."
+> Since this is not a DNS RFC standard and therefore can not be transferred and created in our enterprise DNS. So we need to force CNAME creation instead."
 
 or
 
@@ -251,14 +251,14 @@ If you need to search for multiple ingress classes, you can specify the flag mul
 `--ingress-class=internal --ingress-class=external`.
 
 The `--ingress-class` flag will check both the `spec.ingressClassName` field and the deprecated `kubernetes.io/ingress.class` annotation.
-The `spec.ingressClassName` tasks precedence over the annotation if both are supplied.
+The `spec.ingressClassName` takes precedence over the annotation if both are supplied.
 
 **Backward compatibility**
 
 The previous `--annotation-filter` flag can still be used to restrict which objects ExternalDNS considers; for example, `--annotation-filter=kubernetes.io/ingress.class in (public,dmz)`.
 
 However, beware when using annotation filters with multiple sources, e.g. `--source=service --source=ingress`, since `--annotation-filter` will filter every given source object.
-If you need to use annotation filters against a specific source you have to run a separated external dns service containing only the wanted `--source`  and `--annotation-filter`.
+If you need to use annotation filters against a specific source you have to run a separated external dns service containing only the wanted `--source` and `--annotation-filter`.
 
 Note: the `--ingress-class` flag cannot be used at the same time as the `--annotation-filter=kubernetes.io/ingress.class in (...)` flag; if you do this an error will be raised.
 

docs/tutorials/cloudflare.md

@@ -304,7 +304,7 @@ By setting the TTL annotation on the service, you have to pass a valid TTL, whic
 This annotation is optional, if you won't set it, it will be 1 (automatic) which is 300.
 For Cloudflare proxied entries, set the TTL annotation to 1 (automatic), or do not set it.
 
-ExternalDNS uses this annotation to determine what services should be registered with DNS.  Removing the annotation
+ExternalDNS uses this annotation to determine what services should be registered with DNS. Removing the annotation
 will cause ExternalDNS to remove the corresponding DNS records.
 
 Create the deployment and service:
@@ -339,7 +339,7 @@ kubectl delete -f externaldns.yaml
 
 Using the `external-dns.alpha.kubernetes.io/cloudflare-proxied: "true"` annotation on your ingress, you can specify if the proxy feature of Cloudflare should be enabled for that record. This setting will override the global `--cloudflare-proxied` setting.
 
-## Setting cloudlfare regional services
+## Setting cloudflare regional services
 
 With Cloudflare regional services you can restrict which data centers can decrypt and serve HTTPS traffic.
 

plan/conflict.go

@@ -66,7 +66,7 @@ func (s PerResource) ResolveUpdate(current *endpoint.Endpoint, candidates []*end
 }
 
 // ResolveRecordTypes attempts to detect and resolve record type conflicts in desired
-// endpoints for a domain. For eample if the there is more than 1 candidate and at lease one
+// endpoints for a domain. For example if there is more than 1 candidate and at least one
 // of them is a CNAME. Per [RFC 1034 3.6.2] domains that contain a CNAME can not contain any
 // other record types. The default policy will prefer A and AAAA record types when a conflict is
 // detected (consistent with [endpoint.Targets.Less]).

plan/plan_test.go

@@ -711,7 +711,7 @@ func (suite *PlanTestSuite) TestCurrentWithConflictingDesired() {
 }
 
 // TestNoCurrentWithConflictingDesired simulates where the desired records result in conflicting records types.
-// This could be the result of multiple sources generating conflicting records types. In this case there the
+// This could be the result of multiple sources generating conflicting records types. In this case, the
 // conflict resolver should prefer the A and AAAA record and drop the other candidate record types.
 func (suite *PlanTestSuite) TestNoCurrentWithConflictingDesired() {
 	current := []*endpoint.Endpoint{}

provider/rfc2136/rfc2136_test.go

@@ -547,7 +547,7 @@ func TestRfc2136GetRecords(t *testing.T) {
 }
 
 // Make sure the test version of SendMessage raises an error
-// if a zone update ever contains records outside of it's zone
+// if a zone update ever contains records outside of its zone
 // as the TestRfc2136ApplyChanges tests all assume this
 func TestRfc2136SendMessage(t *testing.T) {
 	stub := newStub()