Let's start this blog by defining the CoreDNS components as we did in the previous blogs in this series.
What is CoreDNS, and how does it work?
CoreDNS is a DNS server that uses a simple plugin system to provide authoritative and recursive name services. It can also act as a proxy for other DNS servers. The main advantage of using Coredns is that it can be used to resolve both internal and external DNS names, making it ideal for use in hybrid environments.
What are the benefits of using Coredns?
There are several benefits to using Coredns, including:
- It is easy to configure and use
- It supports a wide range of DNS features
- It's scalable, quick, and flexible. If a feature isn't available out of the box, you can write a plugin to add it. The term "flexible" refers to the fact that you have a lot of control over your DNS data, which you may exercise using a variety of plugins.
- It is open-source, free to use, and written in Go Language. If you are looking for a reliable and flexible DNS server that can be used in hybrid environments, then Coredns is an excellent choice. You can learn more about it by visiting the Coredns website or downloading a copy of the software today.
Corefile and plugins
To use Coredns, you need to create a Corefile that defines your environment's name servers and other settings. This file is typically stored in /etc/coredns/Corefile or in the directory where the CoreDNS software is installed.
The Corefile can also specify plugins that you want to use to add features to Coredns. For example, the proxy plugin can be used to forward DNS requests to another DNS server. Other available plugins include:
- cache
- loadbalance
- filter
- health
- prometheus You can learn more about plugins and how to use them by visiting the Coredns website or reading the documentation.
Installing Coredns for our Hyperconverged OCP Cluster
CoreDNS can be installed on various operating systems, including Linux, BSD, Windows, and macOS. You can download the software from the Coredns website or use a package manager to install it and manage it separately.
If you look at your existing OpenShift, you'll see that a CoreDNS service operates as pods. However, we require this service before beginning the cluster bootstrap procedure. And the easy way we can deploy CoreDNS is by utilizing the Kubelet static pods strategy. We've already used this method for Keepalived and HAProxy, so let's apply it to CoreDNS.
Let's take a look at CoreDNS static manifest file,
kind: Pod
apiVersion: v1
metadata:
name: coredns
namespace: openshift-openstack-infra
creationTimestamp:
deletionGracePeriodSeconds: 65
labels:
app: openstack-infra-mdns
spec:
volumes:
- name: resource-dir
hostPath:
path: "/etc/kubernetes/static-pod-resources/coredns"
- name: kubeconfig
hostPath:
path: "/var/lib/kubelet"
- name: conf-dir
hostPath:
path: "/etc/coredns"
- name: nm-resolv
hostPath:
path: "/var/run/NetworkManager"
initContainers:
- name: render-config-coredns
image: quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:2ce9667775acdefcff0a90199c2b87b001b98d7ea5b5e7ed18453ba47b318235
command:
- runtimecfg
- render
- "/var/lib/kubelet/kubeconfig"
- "--api-vip"
- "172.21.104.25"
- "--ingress-vip"
- "172.21.104.26"
- "/config"
- "--out-dir"
- "/etc/coredns"
resources: {}
volumeMounts:
- name: kubeconfig
mountPath: "/var/lib/kubelet"
- name: resource-dir
mountPath: "/config"
- name: conf-dir
mountPath: "/etc/coredns"
imagePullPolicy: IfNotPresent
containers:
- name: coredns
securityContext:
privileged: true
image: quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:32a461d8ea341926133857f586dd602f7fe85c608ad93e46d07be7298fb5a6cb
args:
- "--conf"
- "/etc/coredns/Corefile"
resources:
requests:
cpu: 100m
memory: 200Mi
volumeMounts:
- name: conf-dir
mountPath: "/etc/coredns"
livenessProbe:
httpGet:
path: /health
port: 18080
scheme: HTTP
initialDelaySeconds: 60
timeoutSeconds: 5
successThreshold: 1
failureThreshold: 5
terminationMessagePolicy: FallbackToLogsOnError
imagePullPolicy: IfNotPresent
- name: coredns-monitor
securityContext:
privileged: true
image: quay.io/openshift-release-dev/ocp-v4.0-art-dev@sha256:2ce9667775acdefcff0a90199c2b87b001b98d7ea5b5e7ed18453ba47b318235
command:
- corednsmonitor
- "/var/lib/kubelet/kubeconfig"
- "/config/Corefile.tmpl"
- "/etc/coredns/Corefile"
- "--api-vip"
- "172.21.104.25"
- "--ingress-vip"
- "172.21.104.26"
resources:
requests:
cpu: 100m
memory: 200Mi
volumeMounts:
- name: kubeconfig
mountPath: "/var/lib/kubelet"
- name: resource-dir
mountPath: "/config"
- name: conf-dir
mountPath: "/etc/coredns"
- name: nm-resolv
mountPath: "/var/run/NetworkManager"
imagePullPolicy: IfNotPresent
hostNetwork: true
tolerations:
- operator: Exists
priorityClassName: system-node-critical
status: {}
and CoreDNS configs,
. {
errors
bufsize 512
health :18080
forward . {{- range $upstream := .DNSUpstreams}} {{$upstream}}{{- end}} {
policy sequential
}
cache 30
reload
template IN {{ .Cluster.IngressVIPRecordType }} ocp01.telco.ocp.run {
match .*.apps.ocp01.telco.ocp.run
answer "{{"{{ .Name }}"}} 60 in {{"{{ .Type }}"}} 172.21.104.26"
fallthrough
}
template IN {{ .Cluster.IngressVIPEmptyType }} ocp01.telco.ocp.run {
match .*.apps.ocp01.telco.ocp.run
fallthrough
}
template IN {{ .Cluster.APIVIPRecordType }} ocp01.telco.ocp.run {
match api.ocp01.telco.ocp.run
answer "{{"{{ .Name }}"}} 60 in {{"{{ .Type }}"}} 172.21.104.25"
fallthrough
}
template IN {{ .Cluster.APIVIPEmptyType }} ocp01.telco.ocp.run {
match api.ocp01.telco.ocp.run
fallthrough
}
template IN {{ .Cluster.APIVIPRecordType }} ocp01.telco.ocp.run {
match api-int.ocp01.telco.ocp.run
answer "{{"{{ .Name }}"}} 60 in {{"{{ .Type }}"}} 172.21.104.25"
fallthrough
}
template IN {{ .Cluster.APIVIPEmptyType }} ocp01.telco.ocp.run {
match api-int.ocp01.telco.ocp.run
fallthrough
}
hosts {
{{- range .Cluster.NodeAddresses }}
{{ .Address }} {{ .Name }} {{ .Name }}.{{ $.Cluster.Name }}.{{ $.Cluster.Domain }}
{{- end }}
fallthrough
}
}
Top comments (0)