coredns работает, но не готов после вызова k8s cdk

Я развернул Kubernetes V1.18.2 (CDK) с помощью conure-up (который использовал бионический) Обновление: полностью уничтожил вышеуказанный env, а затем снова развернул его вручную, используя пакет CDK здесь https://jaas.ai/canonical-kubernetes, та же версия K8S, та же версия ОС (Ubuntu 18.04) без разницы.

coredns разрешается через /etc/resolv.conf, см. configmap ниже:

Name:         coredns
Namespace:    kube-system
Labels:       cdk-addons=true
Annotations:  
Data
====
Corefile:
----
.:53 {
    errors
    health {
      lameduck 5s
    }
    ready
    kubernetes cluster.local in-addr.arpa ip6.arpa {
      fallthrough in-addr.arpa ip6.arpa
    }
    prometheus :9153
    forward . /etc/resolv.conf
    cache 30
    loop
    reload
    loadbalance
}

Events:  <none>

Здесь есть известная проблема: https://kubernetes.io/docs/tasks/administer-cluster/dns-debugging-resolution/#known-issues о /etc/resolv.conf вместо /run/systemd/resolve/resolv.conf

Я отредактировал coredns конфигурационную карту, чтобы она указала на /run/systemd/resolve/resolv.conf, но настройки возвращаются.

Я также пробовал установить kubelet-extra-config на {resolvConf: /run/systemd/resolve/resolv.conf}, перезапустил сервер, без изменений:

kubelet-extra-config:
    default: '{}'
    description: |
      Extra configuration to be passed to kubelet. Any values specified in this
      config will be merged into a KubeletConfiguration file that is passed to
      the kubelet service via the --config flag. This can be used to override
      values provided by the charm.
      Requires Kubernetes 1.10+.
      The value for this config must be a YAML mapping that can be safely
      merged with a KubeletConfiguration file. For example:
        {evictionHard: {memory.available: 200Mi}}
      For more information about KubeletConfiguration, see upstream docs:
      https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/
    source: user
    type: string
    value: '{resolvConf: /run/systemd/resolve/resolv.conf}'

Но я вижу изменения в kubelet config при проверке конфигурации согласно https://kubernetes.io/docs/tasks/administer-cluster/reconfigure-kubelet/

...
"resolvConf": "/run/systemd/resolve/resolv.conf",
...

Это ошибка, которую я получаю в модуле coredns:

E0429 09:16:42.172959       1 reflector.go:153] pkg/mod/k8s.io/[email protected]/tools/cache/reflector.go:105: Failed to list *v1.Endpoints: Get https://10.152.183.1:443/api/v1/endpoints?limit=500&resourceVersion=0: dial tcp 10.152.183.1:443: i/o timeout
[INFO] plugin/ready: Still waiting on: "kubernetes"

См. Сервис kubernetes:

default                           kubernetes                               ClusterIP   10.152.183.1     <none>        443/TCP                  4h42m   <none>

Вот coredns развертывание:

Name:                   coredns
Namespace:              kube-system
CreationTimestamp:      Wed, 29 Apr 2020 09:15:07 +0000
Labels:                 cdk-addons=true
                        cdk-restart-on-ca-change=true
                        k8s-app=kube-dns
                        kubernetes.io/name=CoreDNS
Annotations:            deployment.kubernetes.io/revision: 1
Selector:               k8s-app=kube-dns
Replicas:               1 desired | 1 updated | 1 total | 0 available | 1 unavailable
StrategyType:           RollingUpdate
MinReadySeconds:        0
RollingUpdateStrategy:  1 max unavailable, 25% max surge
Pod Template:
  Labels:           k8s-app=kube-dns
  Service Account:  coredns
  Containers:
   coredns:
    Image:       rocks.canonical.com:443/cdk/coredns/coredns-amd64:1.6.7
    Ports:       53/UDP, 53/TCP, 9153/TCP
    Host Ports:  0/UDP, 0/TCP, 0/TCP
    Args:
      -conf
      /etc/coredns/Corefile
    Limits:
      memory:  170Mi
    Requests:
      cpu:        100m
      memory:     70Mi
    Liveness:     http-get http://:8080/health delay=60s timeout=5s period=10s #success=1 #failure=5
    Readiness:    http-get http://:8181/ready delay=0s timeout=1s period=10s #success=1 #failure=3
    Environment:  <none>
    Mounts:
      /etc/coredns from config-volume (ro)
  Volumes:
   config-volume:
    Type:               ConfigMap (a volume populated by a ConfigMap)
    Name:               coredns
    Optional:           false
  Priority Class Name:  system-cluster-critical
Conditions:
  Type           Status  Reason
  ----           ------  ------
  Available      True    MinimumReplicasAvailable
  Progressing    False   ProgressDeadlineExceeded
OldReplicaSets:  <none>
NewReplicaSet:   coredns-6b59b8bd9f (1/1 replicas created)
Events:
  Type    Reason             Age   From                   Message
  ----    ------             ----  ----                   -------
  Normal  ScalingReplicaSet  11m   deployment-controller  Scaled up replica set coredns-6b59b8bd9f to 1

Кто-нибудь может помочь, пожалуйста?

Дополнительная информация: K8S SVC настроен правильно:

Name:              kubernetes
Namespace:         default
Labels:            component=apiserver
                   provider=kubernetes
Annotations:       <none>
Selector:          <none>
Type:              ClusterIP
IP:                10.152.183.1
Port:              https  443/TCP
TargetPort:        6443/TCP
Endpoints:         xx.xx.xx.xx:6443,xx.xx.xx.yy:6443
Session Affinity:  None
Events:            <none>

Я могу скрутить оба IP-адреса с помощью --insecure

Описание EP:

kubectl describe ep kubernetes 
Name:         kubernetes
Namespace:    default
Labels:       <none>
Annotations:  <none>
Subsets:
  Addresses:          xx.xx.xx.xx,xx.xx.xx.yy
  NotReadyAddresses:  <none>
  Ports:
    Name   Port  Protocol
    ----   ----  --------
    https  6443  TCP

Events:  <none>

Дополнительные выводы: похоже, что большинство vnet, созданных juju во время CDK развертывания, не работают. Я подозреваю, что это из-за apparmor (на основе https://jaas.ai/canonical-kubernetes/bundle/21)

Примечание. Если вы хотите развернуть этот пакет локально на своем ноутбуке, см. Сегмент о Conjure-Up в разделе «Альтернативные методы развертывания». Развертывание по умолчанию через juju не приведет к правильной настройке профиля apparmor для поддержки работы кубернетов в LXD. В настоящее время это необходимый механизм промежуточного развертывания.

7: vnet0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br1 state UNKNOWN group default qlen 1000
    link/ether fe:54:00:f0:0c:29 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:fef0:c29/64 scope link 
       valid_lft forever preferred_lft forever
70: vnet12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br1 state UNKNOWN group default qlen 1000
    link/ether fe:54:00:00:a3:94 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:fe00:a394/64 scope link 
       valid_lft forever preferred_lft forever
72: vnet13: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br1 state UNKNOWN group default qlen 1000
    link/ether fe:54:00:15:17:f4 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:fe15:17f4/64 scope link 
       valid_lft forever preferred_lft forever
74: vnet14: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br1 state UNKNOWN group default qlen 1000
    link/ether fe:54:00:ec:5c:72 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:feec:5c72/64 scope link 
       valid_lft forever preferred_lft forever
76: vnet15: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br1 state UNKNOWN group default qlen 1000
    link/ether fe:54:00:60:79:18 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:fe60:7918/64 scope link 
       valid_lft forever preferred_lft forever
79: vnet16: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br1 state UNKNOWN group default qlen 1000
    link/ether fe:54:00:67:ff:14 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:fe67:ff14/64 scope link 
       valid_lft forever preferred_lft forever
81: vnet17: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br1 state UNKNOWN group default qlen 1000
    link/ether fe:54:00:96:71:01 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:fe96:7101/64 scope link 
       valid_lft forever preferred_lft forever
83: vnet18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br1 state UNKNOWN group default qlen 1000
    link/ether fe:54:00:a8:1d:b7 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:fea8:1db7/64 scope link 
       valid_lft forever preferred_lft forever
85: vnet19: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br1 state UNKNOWN group default qlen 1000
    link/ether fe:54:00:2a:89:c1 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:fe2a:89c1/64 scope link 
       valid_lft forever preferred_lft forever
87: vnet20: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br1 state UNKNOWN group default qlen 1000
    link/ether fe:54:00:4e:ce:fb brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:fe4e:cefb/64 scope link 
       valid_lft forever preferred_lft forever
89: vnet21: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br1 state UNKNOWN group default qlen 1000
    link/ether fe:54:00:93:55:ac brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:fe93:55ac/64 scope link 
       valid_lft forever preferred_lft forever
90: vnet22: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master br1 state UNKNOWN group default qlen 1000
    link/ether fe:54:00:b7:ae:b2 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::fc54:ff:feb7:aeb2/64 scope link 
       valid_lft forever preferred_lft forever

Еще одно новое обновление: я попробовал развертывание xenial и заметил, что /etc/resolv.conf настроен правильно, без проблем, однако проблема осталась прежней.