Kubefed

Cluster Controller : kubefedcluster라는 CRD로 클러스터들을 Heath 정보 관리 및 추가 삭제 관리

Federated Type : federated deployment, service 등의 클러스터 단위로 배포할 수 있는 리소스들

Status Controller : 멤버 클러스터들의 리소스 상태를 수집하는 컨트롤러

Sync Controller : 멤버 클러스터들의 federated 리소드들을 동기화 하는 컨트롤러

Scheduling Manager : RSP 타입을 관리하기 위한 매니저

RSP Controller : RSPReplicaSchedulingPreference target의 레플리카를 설정한 범위 내에서 유동적으로 조절하게 하는 컨트롤러, 수정된 정보는 API Server에 적용해 Sync Controller로 각 클러스터의 레플리카를 수정

위 구조는 federation된 클러스터간 app 배포를 표현

apiVersion: types.kubefed.io/v1beta1
kind: FederatedDeployment
metadata:
  name: test-deployment
  namespace: test-namespace
spec:
  template:
    metadata:
      labels:
        app: nginx
    spec:
      replicas: 3
      selector:
        matchLabels:
          app: nginx
      template:
        metadata:
          labels:
            app: nginx
        spec:
          containers:
          - image: nginx
            name: nginx
  placement:
    clusters:
    - name: host
    - name: jskim
  overrides:
  - clusterName: host
    clusterOverrides:
    - path: "/spec/replicas"
      value: 5
    - path: "/spec/template/spec/containers/0/image"
      value: "nginx:1.17.0-alpine"
    - path: "/metadata/annotations"
      op: "add"
      value:
        foo: bar
    - path: "/metadata/annotations/foo"
      op: "remove"

federation type으로 분류된 Template, Placement, Overrides는 각각 app의 기본 정보, 배포될 클러스터 선정, 변수의 재정의를 의미

 

kubefed에서 지원하는 federated resource type은 다음과 같음

cluster role

cluster role binding

config map

deployment

ingress

job

namespace

secret

service

serviceaccount

해당 파일들의 예제는 다음 URL을 통해 확인할 수 있음

kubefed/example/sample1 at master · kubernetes-sigs/kubefed · GitHub

 

 

명령어

기본적으로 control plane에서 동작한다고 가정

만약 아닐 경우 flag로 --host-cluster-context로 호스트 클러스터를 지정

 

kubefedctl disable [Name] [flag]

K8s의 API 유형 (ex. deployment.app)을 배포하지 않도록 설정하거나 enable 명령어로 추가된 리소스를 삭제

 

kubefedctl enable [Name or -f filename] [flag]

CRD포함 K8s의 API 유형을 배포

 

kubefedctl federate [Type name] [Resource name] [flag]

K8s에서 지원하는 기본 리소스를 통해 federated 리소스를 생성

 

kubefedctl join [Cluster name] --host-cluster-context=[Host cluster context] [flag]

Cluster를 Host cluster에 등록

 

kubesphere를 통하지 않는다면 join 명령어를 통해 등록해야 하는데 그 과정에서 어떠한 방식으로든 대상 클러스터의 정보를 가지고 있어야 함

config 파일에 cluster context와 인증 데이터를 넣어 등록하거나 혹은 flag 중 secret-name이 존재하는데 해당 클러스터의 인증 정보를 가진 secret을 연결해 사용

대부분의 경우 member의 config 정보를 가져와 host의 config 정보에 삽입하는 방식으로 사용

 

--secret-name string

Name of the secret where the cluster's credentials will be stored in the host cluster. This name should be a valid RFC 1035 label. If unspecified, defaults to a generated name containing the cluster name.

 

kubefedctl unjoin [Cluster name] --host-cluster-context=[Host cluster context] [flag]

Cluster를 Host cluster에서 삭제

 

kubefedctl orphaning-deletion [flag or command]

Resource 삭제 시 정책

command

disable

Resource의 삭제가 실행 되었을 때 관리되는 리소스를 제거

enable

Resource의 삭제가 실행 되었을 때 관리되는 리소스를 보존

status

Federated resource의 상태 정보

 

version

help

 

 

Kubefed를 통한 federation 구현

 

host cluster에서 진행함이 기본

 

헬름을 통해 kubefed를 설치

centos# helm repo add kubefed-charts https://raw.githubusercontent.com/kubernetes-sigs/kubefed/master/charts

centos# helm --namespace kube-federation-system upgrade -i kubefed kubefed-charts/kubefed --version=<x.x.x> --create-namespace

<x.x.x>에 버전을 기입하여 설치

글 작성 기준 0.9.1 버전이 가장 최신 버전이므로 --version=0.9.1로 기입

 

위 방법으로 kubefed는 설치되었지만 제어하기 위한 ctl는 설치되지 않은 상태

centos# wget https://github.com/kubernetes-sigs/kubefed/releases/download/v0.9.1/kubefedctl-0.9.1-linux-amd64.tgz

위에서 설치했던 버전과 동일한 버전의 ctl을 설치

centos# tar -zxvf kubefedctl-0.9.1-linux-amd64.tgz

centos# chmod u+x kubefedctl

centos# mv kubefedctl /usr/local/bin/

권한을 부여하고 해당 경로로 이동

 

federation할 클러스터를 위해 service account와 cluster role을 정의하고 binding

apiVersion: v1
kind: ServiceAccount
metadata:
 labels:
   name: ubuntu-jh
 name: ubuntu-jh
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
 labels:
   name: ubuntu-jh
 name: ubuntu-jh
rules:
 - apiGroups: ['*']
   resources: ['*']
   verbs: ['*']
 - nonResourceURLs: ['*']
   verbs: ['*']
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
 labels:
   name: ubuntu-jh
 name: ubuntu-jh
roleRef:
 apiGroup: rbac.authorization.k8s.io
 kind: ClusterRole
 name: ubuntu-jh
subjects:
 - kind: ServiceAccount
   name: ubuntu-jh
   namespace: default

member가 될 cluster에서 정보를 가져와 적용

host cluster의 kube config 파일에 새로운 context와 cluster 정보를 기입

clusters:
- cluster:
    certificate-authority-data: ... 
    server: https://192.168.0.97:6443 # 호스트 클러스터의 ip
  name: cluster.local
- cluster:
    certificate-authority-data: ... # 멤버 클러스터 추가 부분
    server: https://192.168.0.15:6443 # 멤버 클러스터의 ip
  name: ubuntu-jh
contexts:
- context:
    cluster: cluster.local
    user: kubernetes-admin
  name: kubernetes-admin
- context: # 멤버 클러스터 추가 부분
    cluster: ubuntu-jh # 멤버 클러스터 추가 부분
    user: ubuntu-jh # 멤버 클러스터 추가 부분
  name: ubuntu-jh # 멤버 클러스터 추가 부분
current-context: kubernetes-admin
kind: Config
preferences: {}
users:
- name: kubernetes-admin
  user:
    client-certificate-data: ...
    client-key-data: ...
- name: ubuntu-jh # 멤버 클러스터 추가 부분
  user: # 멤버 클러스터 추가 부분
    client-certificate-data: ... # 멤버 클러스터 추가 부분
    client-key-data: ... # 멤버 클러스터 추가 부분

추가 부분들은 member cluster의 kube config을 참고하여 기입

 

여기까지 진행하였다면 config 관련 명령어를 통해 member cluster에 접근이 가능

kubefedctl join 명령어를 통해 federation을 진행

 

centos# kubefedctl join kubernetes-admin --host-cluster-context kubernetes-admin --v=2

centos# kubefedctl join ubuntu-jh --host-cluster-context kubernetes-admin --v=2

 

위 두 명령어를 진행한다면 다음 명령어를 통해 성공적으로 federation 되었는지 확인

centos# kubectl get kubefedcluster -n kube-federation-system

 

이제 federated 관련 CDR을 사용할 수 있게 되는데 가장 먼저 배포해야 하는것은 federatednamespace로 선행으로 배포하고 배포된 namespace로 배포하지 않으면 사용이 불가능함을 확인

apiVersion: types.kubefed.io/v1beta1
kind: FederatedNamespace
metadata:
  name: test-namespace
  namespace: test-namespace
spec:
  placement:
    clusters:
    - name: kubernetes-admin 
    - name: ubuntu-jh

기초되는 틀은 위와 같으며 위 federatednamespace를 위한 네임 스페이스 역시 필요하니 배포 필요

 

특이한 타입으로 ReplicaSchedulingPreference이 존재

apiVersion: scheduling.kubefed.io/v1alpha1
kind: ReplicaSchedulingPreference
metadata:
  name: test-deployment
  namespace: test-namespace
spec:
  targetKind: FederatedDeployment
  totalReplicas: 10
  clusters:
   kubernetes-admin:
     weight: 2
     maxReplicas: 5
   ubuntu-jh:
     weight: 3
     minReplicas: 0
     maxReplicas: 0

위와 같은 방식으로 사용되며 먼저 같은 이름의 targetKind가 존재해야 사용 가능

가중치와 min, max로 total에 해당하는 갯 수만큼의 pod가 배포되며, min, max가 우선 순위를 가짐