etcd Kubernetes 클러스터의 데이터에 대한 당사의 경험(K8s API 없음)

점점 더 많은 고객이 클러스터 내의 서비스에 액세스할 수 있도록 Kubernetes 클러스터에 대한 액세스를 제공해달라고 요청하고 있습니다. 이를 통해 일부 데이터베이스나 서비스에 직접 연결하고 로컬 애플리케이션을 클러스터 내의 애플리케이션과 연결할 수 있습니다.

예를 들어 로컬 컴퓨터에서 서비스로 연결해야 하는 경우가 있습니다. memcached.staging.svc.cluster.local. 우리는 클라이언트가 연결되는 클러스터 내의 VPN을 사용하여 이 기능을 제공합니다. 이를 위해 포드, 서비스의 서브넷을 알리고 클러스터 DNS를 클라이언트에 푸시합니다. 따라서 클라이언트가 서비스에 연결을 시도할 때 memcached.staging.svc.cluster.local, 요청은 클러스터 DNS로 이동하고 이에 대한 응답으로 클러스터 서비스 네트워크 또는 Pod 주소에서 이 서비스의 주소를 받습니다.

kubeadm을 사용하여 K8s 클러스터를 구성합니다. 여기서 기본 서비스 서브넷은 다음과 같습니다. 192.168.0.0/16이고 포드 네트워크는 다음과 같습니다. 10.244.0.0/16. 일반적으로 모든 것이 잘 작동하지만 몇 가지 사항이 있습니다.

• 서브넷 192.168.*.* 클라이언트 사무실 네트워크에서 자주 사용되며 개발자 홈 네트워크에서는 훨씬 더 자주 사용됩니다. 그런 다음 충돌이 발생합니다. 홈 라우터는 이 서브넷에서 작동하고 VPN은 이러한 서브넷을 클러스터에서 클라이언트로 푸시합니다.
• 여러 클러스터(프로덕션, 스테이지 및/또는 여러 개발 클러스터)가 있습니다. 그런 다음 기본적으로 모든 클러스터는 포드와 서비스에 대해 동일한 서브넷을 갖게 되므로 여러 클러스터의 서비스를 동시에 작업하는 데 큰 어려움이 발생합니다.

우리는 일반적으로 모든 클러스터가 서로 다른 네트워크를 갖도록 동일한 프로젝트 내의 서비스 및 포드에 대해 서로 다른 서브넷을 사용하는 방식을 오래 전부터 채택했습니다. 그러나 운영 중인 클러스터는 많은 서비스, 상태 저장 애플리케이션 등을 실행하기 때문에 처음부터 롤오버하고 싶지 않습니다.

그런 다음 우리는 스스로에게 질문했습니다. 기존 클러스터에서 서브넷을 변경하는 방법은 무엇입니까?

솔루션 검색

가장 일반적인 방법은 다시 만드는 것입니다. 모든 ClusterIP 유형의 서비스. 옵션으로, 조언할 수 있다 등 :

다음 프로세스에는 문제가 있습니다. 모든 구성이 완료된 후 포드는 /etc/resolv.conf에서 이전 IP를 DNS 이름 서버로 사용합니다.
여전히 해결책을 찾지 못했기 때문에 kubeadm Reset을 사용하여 전체 클러스터를 재설정하고 다시 초기화해야 했습니다.

그러나 이것은 모든 사람에게 적합하지 않습니다... 우리 사례에 대한 자세한 소개는 다음과 같습니다.

• 플란넬이 사용됩니다.
• 클라우드와 하드웨어 모두에 클러스터가 있습니다.
• 클러스터의 모든 서비스를 재배포하는 것을 피하고 싶습니다.
• 일반적으로 최소한의 문제로 모든 작업을 수행할 필요가 있습니다.
• Kubernetes 버전은 1.16.6입니다(그러나 추가 단계는 다른 버전에서도 유사합니다).
• 주요 작업은 서비스 서브넷과 함께 kubeadm을 사용하여 배포된 클러스터에서 192.168.0.0/16, 다음으로 대체 172.24.0.0/16.

그리고 우리는 Kubernetes에서 etcd에 무엇을 어떻게 저장하는지, 이를 통해 무엇을 할 수 있는지 오랫동안 관심을 가져왔습니다. 그래서 우리는 다음과 같이 생각했습니다.etcd의 데이터를 업데이트하고 기존 IP 주소(서브넷)를 새 IP 주소(서브넷)로 바꾸는 것은 어떨까요??»

etcd의 데이터 작업을 위해 기성 도구를 검색했지만 문제를 완전히 해결하는 도구를 찾지 못했습니다. (그런데 etcd에서 직접 데이터를 작업할 수 있는 유틸리티에 대해 알고 계시다면 링크를 알려주시면 감사하겠습니다.) 그러나 좋은 출발점은 etcdhelper 오픈시프트에서 (저자들에게 감사드립니다!).

이 유틸리티는 인증서를 사용하여 etcd에 연결하고 명령을 사용하여 그곳에서 데이터를 읽을 수 있습니다. ls, get, dump.

etcdhelper 추가

다음 생각은 논리적입니다. "etcd에 데이터를 쓰는 기능을 추가하여 이 유틸리티를 추가하는 것을 막는 이유는 무엇입니까?"

두 가지 새로운 기능을 갖춘 etcdhelper의 수정된 버전이 되었습니다. changeServiceCIDR и changePodCIDR. 그녀에게 코드를 볼 수 있어요 여기에.

새로운 기능의 기능은 무엇인가요? 연산 changeServiceCIDR:

• 디시리얼라이저를 생성합니다.
• CIDR을 대체하기 위해 정규식을 컴파일합니다.
• 클러스터에서 ClusterIP 유형을 사용하는 모든 서비스를 살펴보겠습니다.
  • etcd의 값을 Go 객체로 디코딩합니다.
  • 정규식을 사용하여 주소의 처음 XNUMX바이트를 바꿉니다.
  • 서비스에 새 서브넷의 IP 주소를 할당합니다.
  • 직렬 변환기를 만들고, Go 개체를 protobuf로 변환하고, etcd에 새 데이터를 씁니다.

기능 changePodCIDR 본질적으로 유사 changeServiceCIDR - 서비스 사양을 편집하는 대신 노드에 대해서만 편집하고 변경합니다. .spec.PodCIDR 새 서브넷으로.

연습

서비스 CIDR 변경

작업 구현 계획은 매우 간단하지만 클러스터의 모든 포드를 다시 생성할 때 다운타임이 발생합니다. 주요 단계를 설명한 후, 이론적으로 이러한 다운타임을 최소화할 수 있는 방법에 대한 생각도 공유하겠습니다.

준비 단계:

• 필요한 소프트웨어를 설치하고 패치된 etcdhelper를 조립합니다.
• etcd 백업 및 /etc/kubernetes.

serviceCIDR 변경을 위한 간략한 실행 계획:

• apiserver 및 컨트롤러 관리자 매니페스트 변경
• 인증서 재발급;
• etcd에서 ClusterIP 서비스를 변경합니다.
• 클러스터의 모든 포드를 다시 시작합니다.

다음은 전체 작업 순서를 자세히 설명한 것입니다.

1. 데이터 덤프를 위해 etcd-client를 설치합니다.

apt install etcd-client

2. etcdhelper를 빌드하십시오.

• Golang을 설치합니다:

  GOPATH=/root/golang
  mkdir -p $GOPATH/local
  curl -sSL https://dl.google.com/go/go1.14.1.linux-amd64.tar.gz | tar -xzvC $GOPATH/local
  echo "export GOPATH="$GOPATH"" >> ~/.bashrc
  echo 'export GOROOT="$GOPATH/local/go"' >> ~/.bashrc
  echo 'export PATH="$PATH:$GOPATH/local/go/bin"' >> ~/.bashrc

• 우리는 우리 자신을 위해 저축합니다 etcdhelper.go, 종속성을 다운로드하고 다음을 수집합니다.

  wget https://raw.githubusercontent.com/flant/examples/master/2020/04-etcdhelper/etcdhelper.go
  go get go.etcd.io/etcd/clientv3 k8s.io/kubectl/pkg/scheme k8s.io/apimachinery/pkg/runtime
  go build -o etcdhelper etcdhelper.go

3. 백업 etcd를 만드십시오:

backup_dir=/root/backup
mkdir ${backup_dir}
cp -rL /etc/kubernetes ${backup_dir}
ETCDCTL_API=3 etcdctl --cacert=/etc/kubernetes/pki/etcd/ca.crt --key=/etc/kubernetes/pki/etcd/server.key --cert=/etc/kubernetes/pki/etcd/server.crt --endpoints https://192.168.199.100:2379 snapshot save ${backup_dir}/etcd.snapshot

4. Kubernetes 제어 플레인 매니페스트에서 서비스 서브넷을 변경합니다. 파일에서 /etc/kubernetes/manifests/kube-apiserver.yaml и /etc/kubernetes/manifests/kube-controller-manager.yaml 매개변수를 변경해 보세요 --service-cluster-ip-range 새 서브넷으로: 172.24.0.0/16 대신 192.168.0.0/16.

5. kubeadm이 apiserver에 대한 인증서(포함)를 발급하는 서비스 서브넷을 변경하고 있으므로 재발급해야 합니다.

1. 현재 인증서가 발급된 도메인과 IP 주소를 살펴보겠습니다.

   openssl x509 -noout -ext subjectAltName </etc/kubernetes/pki/apiserver.crt
   X509v3 Subject Alternative Name:
       DNS:dev-1-master, DNS:kubernetes, DNS:kubernetes.default, DNS:kubernetes.default.svc, DNS:kubernetes.default.svc.cluster.local, DNS:apiserver, IP Address:192.168.0.1, IP Address:10.0.0.163, IP Address:192.168.199.100

2. kubeadm에 대한 최소 구성을 준비해 보겠습니다.

   cat kubeadm-config.yaml
   apiVersion: kubeadm.k8s.io/v1beta1
   kind: ClusterConfiguration
   networking:
     podSubnet: "10.244.0.0/16"
     serviceSubnet: "172.24.0.0/16"
   apiServer:
     certSANs:
     - "192.168.199.100" # IP-адрес мастер узла

3. 기존 crt와 키를 삭제해 보겠습니다. 삭제하지 않으면 새 인증서가 발급되지 않습니다.

   rm /etc/kubernetes/pki/apiserver.{key,crt}

4. API 서버에 대한 인증서를 재발급해 보겠습니다.

   kubeadm init phase certs apiserver --config=kubeadm-config.yaml

5. 새 서브넷에 대해 인증서가 발급되었는지 확인해 보겠습니다.

   openssl x509 -noout -ext subjectAltName </etc/kubernetes/pki/apiserver.crt
   X509v3 Subject Alternative Name:
       DNS:kube-2-master, DNS:kubernetes, DNS:kubernetes.default, DNS:kubernetes.default.svc, DNS:kubernetes.default.svc.cluster.local, IP Address:172.24.0.1, IP Address:10.0.0.163, IP Address:192.168.199.100

6. API 서버 인증서를 다시 발급한 후 해당 컨테이너를 다시 시작합니다.

   docker ps | grep k8s_kube-apiserver | awk '{print $1}' | xargs docker restart

7. 구성을 다시 생성해 보겠습니다. admin.conf:

   kubeadm alpha certs renew admin.conf

8. etcd의 데이터를 편집해 보겠습니다.

   ./etcdhelper -cacert /etc/kubernetes/pki/etcd/ca.crt -cert /etc/kubernetes/pki/etcd/server.crt -key /etc/kubernetes/pki/etcd/server.key -endpoint https://127.0.0.1:2379 change-service-cidr 172.24.0.0/16 

   경고! 현재 기존 포드에서는 도메인 확인이 클러스터에서 작동을 중지합니다. /etc/resolv.conf 이전 CoreDNS 주소(kube-dns)가 등록되고 kube-proxy는 iptables 규칙을 이전 서브넷에서 새 서브넷으로 변경합니다. 또한 이 기사에서는 가동 중지 시간을 최소화하기 위한 가능한 옵션에 대해 설명합니다.

9. 네임스페이스에서 ConfigMap을 수정해 보겠습니다. kube-system:

   kubectl -n kube-system edit cm kubelet-config-1.16

   - 여기에서 교체 clusterDNS kube-dns 서비스의 새 IP 주소로: kubectl -n kube-system get svc kube-dns.

   kubectl -n kube-system edit cm kubeadm-config

   - 우리가 고쳐줄게 data.ClusterConfiguration.networking.serviceSubnet 새 서브넷으로.

10. kube-dns 주소가 변경되었으므로 모든 노드에서 kubelet 구성을 업데이트해야 합니다.

    kubeadm upgrade node phase kubelet-config && systemctl restart kubelet

11. 남은 것은 클러스터의 모든 Pod를 다시 시작하는 것입니다.

    kubectl get pods --no-headers=true --all-namespaces |sed -r 's/(S+)s+(S+).*/kubectl --namespace 1 delete pod 2/e'

가동 중지 시간 최소화

가동 중지 시간을 최소화하는 방법에 대한 생각:

1. 제어 플레인 매니페스트를 변경한 후 예를 들어 다음 이름을 사용하여 새 kube-dns 서비스를 생성합니다. kube-dns-tmp 그리고 새 주소 172.24.0.10.
2. 확인 if kube-dns 서비스를 수정하지 않는 etcdhelper에서.
3. 모든 kubelet의 주소를 바꿉니다. ClusterDNS 이전 서비스는 새 서비스와 동시에 계속 작동합니다.
4. 애플리케이션이 포함된 포드가 자연스러운 이유로 또는 합의된 시간에 자동으로 롤오버될 때까지 기다립니다.
5. 서비스 삭제 kube-dns-tmp 그리고 변화 serviceSubnetCIDR kube-dns 서비스의 경우.

이 계획을 사용하면 서비스 제거 기간 동안 가동 중지 시간을 최대 XNUMX분으로 최소화할 수 있습니다. kube-dns-tmp 서비스의 서브넷 변경 kube-dns.

포드네트워크 수정

동시에 결과 etcdhelper를 사용하여 podNetwork를 수정하는 방법을 살펴보기로 결정했습니다. 작업 순서는 다음과 같습니다.

• 구성 수정 중 kube-system;
• kube-controller-manager 매니페스트 수정
• etcd에서 직접 podCIDR을 변경합니다.
• 모든 클러스터 노드를 재부팅합니다.

이제 이러한 작업에 대해 자세히 알아보세요.

1. 네임스페이스에서 ConfigMap 수정 kube-system:

kubectl -n kube-system edit cm kubeadm-config

- 교정 data.ClusterConfiguration.networking.podSubnet 새 서브넷으로 10.55.0.0/16.

kubectl -n kube-system edit cm kube-proxy

- 교정 data.config.conf.clusterCIDR: 10.55.0.0/16.

2. 컨트롤러-관리자 매니페스트를 수정합니다.

vim /etc/kubernetes/manifests/kube-controller-manager.yaml

- 교정 --cluster-cidr=10.55.0.0/16.

3. 현재 가치를 살펴보세요 .spec.podCIDR, .spec.podCIDRs, .InternalIP, .status.addresses 모든 클러스터 노드에 대해:

kubectl get no -o json | jq '[.items[] | {"name": .metadata.name, "podCIDR": .spec.podCIDR, "podCIDRs": .spec.podCIDRs, "InternalIP": (.status.addresses[] | select(.type == "InternalIP") | .address)}]'

[
  {
    "name": "kube-2-master",
    "podCIDR": "10.244.0.0/24",
    "podCIDRs": [
      "10.244.0.0/24"
    ],
    "InternalIP": "192.168.199.2"
  },
  {
    "name": "kube-2-master",
    "podCIDR": "10.244.0.0/24",
    "podCIDRs": [
      "10.244.0.0/24"
    ],
    "InternalIP": "10.0.1.239"
  },
  {
    "name": "kube-2-worker-01f438cf-579f9fd987-5l657",
    "podCIDR": "10.244.1.0/24",
    "podCIDRs": [
      "10.244.1.0/24"
    ],
    "InternalIP": "192.168.199.222"
  },
  {
    "name": "kube-2-worker-01f438cf-579f9fd987-5l657",
    "podCIDR": "10.244.1.0/24",
    "podCIDRs": [
      "10.244.1.0/24"
    ],
    "InternalIP": "10.0.4.73"
  }
]

4. etcd를 직접 변경하여 podCIDR을 교체합니다.

./etcdhelper -cacert /etc/kubernetes/pki/etcd/ca.crt -cert /etc/kubernetes/pki/etcd/server.crt -key /etc/kubernetes/pki/etcd/server.key -endpoint https://127.0.0.1:2379 change-pod-cidr 10.55.0.0/16

5. podCIDR이 실제로 변경되었는지 확인해 보겠습니다.

kubectl get no -o json | jq '[.items[] | {"name": .metadata.name, "podCIDR": .spec.podCIDR, "podCIDRs": .spec.podCIDRs, "InternalIP": (.status.addresses[] | select(.type == "InternalIP") | .address)}]'

[
  {
    "name": "kube-2-master",
    "podCIDR": "10.55.0.0/24",
    "podCIDRs": [
      "10.55.0.0/24"
    ],
    "InternalIP": "192.168.199.2"
  },
  {
    "name": "kube-2-master",
    "podCIDR": "10.55.0.0/24",
    "podCIDRs": [
      "10.55.0.0/24"
    ],
    "InternalIP": "10.0.1.239"
  },
  {
    "name": "kube-2-worker-01f438cf-579f9fd987-5l657",
    "podCIDR": "10.55.1.0/24",
    "podCIDRs": [
      "10.55.1.0/24"
    ],
    "InternalIP": "192.168.199.222"
  },
  {
    "name": "kube-2-worker-01f438cf-579f9fd987-5l657",
    "podCIDR": "10.55.1.0/24",
    "podCIDRs": [
      "10.55.1.0/24"
    ],
    "InternalIP": "10.0.4.73"
  }
]

6. 모든 클러스터 노드를 하나씩 재부팅해 보겠습니다.

7. 하나 이상의 노드를 탈퇴하는 경우 이전 PodCIDR, 그러면 kube-controller-manager를 시작할 수 없으며 클러스터의 Pod가 예약되지 않습니다.

실제로 podCIDR 변경은 훨씬 더 간단하게 수행할 수 있습니다(예: 그래서). 하지만 etcd에서 Kubernetes 객체를 편집하는 경우가 있기 때문에 etcd로 직접 작업하는 방법을 배우고 싶었습니다. 단 하나의 가능한 변형. (예를 들어 다운타임 없이 서비스 필드만 변경할 수는 없습니다. spec.clusterIP.)

합계

이 기사에서는 etcd의 데이터로 직접 작업할 수 있는 가능성에 대해 설명합니다. Kubernetes API를 우회합니다. 때때로 이 접근 방식을 사용하면 "까다로운 작업"을 수행할 수 있습니다. 실제 K8s 클러스터에서 텍스트에 제공된 작업을 테스트했습니다. 그러나 널리 사용하기 위한 준비 상태는 다음과 같습니다. PoC(개념 증명). 따라서 클러스터에서 수정된 버전의 etcdhelper 유틸리티를 사용하려는 경우 이에 대한 책임은 사용자에게 있습니다.

PS

블로그에서도 읽어보세요.

• «etcd 3.4.3: 스토리지 안정성 및 보안 연구";
• «Kubernetes 네트워킹을 위한 Calico: 소개 및 약간의 경험";
• «쿠버네티스 운영의 재미있는 시스템 버그 6가지 [및 해당 솔루션]";
• «Kubernetes 문제 해결을 위한 시각적 가이드".

출처 : habr.com