* A full demo on GKE Kubernetes. See [How-to Kubernetes with DNS management (ssl-manager pre-req)](https://medium.com/@jpantjsoha/how-to-kubernetes-with-dns-management-for-gitops-31239ea75d8d)
* Run external-dns on GKE with workload identity. See [Kubernetes, ingress-nginx, cert-manager & external-dns](https://blog.atomist.com/kubernetes-ingress-nginx-cert-manager-external-dns/)
$gcloud dns record-sets transaction execute --zone"gcp-zalan-do"
```
## Deploy ExternalDNS
### Role-Based Access Control (RBAC)
[RBAC]("https://cloud.google.com/kubernetes-engine/docs/how-to/role-based-access-control") is enabled by default on all Container clusters which are running Kubernetes version 1.6 or higher.
Because of the way Container Engine checks permissions when you create a Role or ClusterRole, you must first create a RoleBinding that grants you all of the permissions included in the role you want to create.
Then apply one of the following manifests file to deploy ExternalDNS.
Then apply the following manifests file to deploy ExternalDNS.
### Manifest (for clusters without RBAC enabled)
```yaml
apiVersion:apps/v1
kind:Deployment
metadata:
name:external-dns
spec:
strategy:
type:Recreate
selector:
matchLabels:
app:external-dns
template:
metadata:
labels:
app:external-dns
spec:
containers:
-name:external-dns
image:k8s.gcr.io/external-dns/external-dns:v0.7.3
args:
---source=service
---source=ingress
---domain-filter=external-dns-test.gcp.zalan.do# will make ExternalDNS see only the hosted zones matching provided domain, omit to process all available hosted zones
---provider=google
# - --google-project=zalando-external-dns-test # Use this to specify a project different from the one external-dns is running inside
---policy=upsert-only# would prevent ExternalDNS from deleting any records, omit to enable full synchronization
---registry=txt
---txt-prefix=extdns# when using `registry=txt` option, make sure to also use the `txt-prefix` and `txt-owner-id` options as well. If you try to create a `TXT` record without a prefix, it will try to create a `TXT` record with the same name as your actual DNS record and fail (creating a stranded record `external-dns` cannot manage).
---txt-owner-id=my-identifier
```
### Manifest (for clusters with RBAC enabled)
```yaml
apiVersion:v1
kind:ServiceAccount
...
...
@@ -171,8 +130,7 @@ spec:
Use `--dry-run` if you want to be extra careful on the first run. Note, that you will not see any records created when you are running in dry-run mode. You can, however, inspect the logs and watch what would have been done.
## Verify ExternalDNS works
### Verify ExternalDNS works
Create the following sample application to test that ExternalDNS works.
$gcloud dns record-sets transaction execute --zone=gcp-zalan-do
```
## User Demo How-To Blogs and Examples
* A full demo on GKE Kubernetes + CloudDNS + SA-Permissions [How-to Kubernetes with DNS management (ssl-manager pre-req)](https://medium.com/@jpantjsoha/how-to-kubernetes-with-dns-management-for-gitops-31239ea75d8d)
* Run external-dns on GKE with workload identity. See [Kubernetes, ingress-nginx, cert-manager & external-dns](https://blog.atomist.com/kubernetes-ingress-nginx-cert-manager-external-dns/)
This tutorial describes how to setup ExternalDNS for usage within a GKE cluster that doesn't make use of Google's [default ingress controller](https://github.com/kubernetes/ingress-gce) but rather uses [nginx-ingress-controller](https://github.com/kubernetes/ingress-nginx) for that task.
## Set up your environment
Setup your environment to work with Google Cloud Platform. Fill in your values as needed, e.g. target project.
```console
...
...
@@ -10,6 +12,14 @@ $ gcloud config set compute/region "europe-west1"
$gcloud config set compute/zone "europe-west1-d"
```
## GKE Node Scopes
The following instructions use instance scopes to provide ExternalDNS with the
permissions it needs to manage DNS records. Note that since these permissions
are associated with the instance, all pods in the cluster will also have these
permissions. As such, this approach is not suitable for anything but testing
environments.
Create a GKE cluster without using the default ingress controller.
$gcloud dns record-sets transaction execute --zone"gcp-zalan-do"
```
If you decide not to create a new zone but reuse an existing one, make sure it's currently **unused** and **empty**. This version of ExternalDNS will remove all records it doesn't recognize from the zone.
Connect your `kubectl` client to the cluster you just created.
Connect your `kubectl` client to the cluster you just created and bind your GCP
First, you need to deploy the nginx-based ingress controller. It can be deployed in at least two modes: Leveraging a Layer 4 load balancer in front of the nginx proxies or directly targeting pods with hostPorts on your worker nodes. ExternalDNS doesn't really care and supports both modes.
### Default Backend
#### Default Backend
The nginx controller uses a default backend that it serves when no Ingress rule matches. This is a separate Service that can be picked by you. We'll use the default backend that's used by other ingress controllers for that matter. Apply the following manifests to your cluster to deploy the default backend.
...
...
@@ -96,7 +107,7 @@ spec:
image:gcr.io/google_containers/defaultbackend:1.3
```
### Without a separate TCP load balancer
#### Without a separate TCP load balancer
By default, the controller will update your Ingress objects with the public IPs of the nodes running your nginx controller instances. You should run multiple instances in case of pod or node failure. The controller will do leader election and will put multiple IPs as targets in your Ingress objects in that case. It could also make sense to run it as a DaemonSet. However, we'll just run a single replica. You have to open the respective ports on all of your worker nodes to allow nginx to receive traffic.
...
...
@@ -145,7 +156,7 @@ spec:
hostPort:443
```
### With a separate TCP load balancer
#### With a separate TCP load balancer
However, you can also have the ingress controller proxied by a Kubernetes Service. This will instruct the controller to populate this Service's external IP as the external IP of the Ingress. This exposes the nginx proxies via a Layer 4 load balancer (`type=LoadBalancer`) which is more reliable than the other method. With that approach, you can run as many nginx proxy instances on your cluster as you like or have them autoscaled. This is the preferred way of running the nginx controller.
...
...
@@ -206,7 +217,7 @@ spec:
-containerPort:443
```
## Deploy ExternalDNS
### Deploy ExternalDNS
Apply the following manifest file to deploy ExternalDNS.
...
...
@@ -274,7 +285,7 @@ spec:
Use `--dry-run` if you want to be extra careful on the first run. Note, that you will not see any records created when you are running in dry-run mode. You can, however, inspect the logs and watch what would have been done.
## Deploy a sample application
### Deploy a sample application
Create the following sample application to test that ExternalDNS works.
$gcloud dns record-sets transaction execute --zone=gcp-zalan-do
```
## User Demo How-To Blogs and Examples
* Run external-dns on GKE with workload identity. See [Kubernetes, ingress-nginx, cert-manager & external-dns](https://blog.atomist.com/kubernetes-ingress-nginx-cert-manager-external-dns/)