티스토리 뷰
Cluster API
VMWARE에서 시작한 OpenSource Project로 Kubernetes의 서브 프로젝트로 선언적 API들과 다수의 Kubernetes Cluster들을 쉽게 운영하고 업그레이드, 배포하기 위한 도구로서 제공되는것에 초점을 맞추고 있다.
Cluster API는 kubernetes cluster 전체주기관리(생성,설정,업그레이드,제거)에 대한 선언적인 접근과 kuberetes 스타일의 API를 가져오는 프로젝트이다. Cluster API를 통해 다음과 같은 기능을 수행할 수 있다.
- multi-master 안정된 Kubernetes cluster들을 배포할수 있다.
- Kubernetes cluster 초기의 요구되는 모든것을 배포하고 관리할수 있다.
- 보안 best practices를 구현할수 있다.(security groups, 분리된 subnets, bastion host 등)
- rolling 기반에 Control Plane과 worker들을 업그레이드 할수 있다.
- 다양한 Cloud Providder들을 지원한다.(예, public, private, and bare-metal)
(출처 : https://www.spectrocloud.com/blog/cluster-api-for-kubernetes-infrastructure-management/)
참고로 현재 시점(2021.03)에 아직 안정화 버전이 아니기에 충분한 테스트와 함께 사용이 필요할것이라 판단된다.
Architecture
- Management Cluster
workload cluster들의 생명주기를 관리하는 kubernetes cluster이다.
이는 한개이상의 infrastructure Provider들에 동작될수 있다. - workload Cluster
배포될 Kubernetes를 의미한다. - Infrastcture provider
실제 machine이 동작되고 네트워킹과 컴퓨팅과 같은 자원으로 사용될 것들이 존재하는 provider이다. - Bootstrap provider
cluster의 인증서를 생성하고 control plane을 초기화하고 배포가 완료될때까지 다른 노드들을 생성을 확인한다.
또한 control plane과 worker node들을 cluster에 합류시킨다. - Control Plane
kubernetes API와 요구된 상태에 대한 제어루프를 사용한 지속적인 합의를 제공하는 서비스의 집합이다. - 출처 : https://cluster-api.sigs.k8s.io/user/concepts.html#concepts
다음과 같은 CRD들이 생성된다.
- Machine : 선언적인 spec으로 kubernetes node로 호스팅되는 인프라 구성요소를 위한 것들이다.
(여기서 Machine은 immutability 형태로 해당 node가 업데이트되지 않고 삭제후 재생성되는 개념이다.) - MachineDeployment : Machine과 MachineSet들에 대한 선언적인 update를 제공한다.
(이름처럼 k8s의 deployment와 유사하게 동작한다. - MachineSet :
(이름처럼 kubernetes의 ReplicaSet과 유사하게 동작한다.) - MachineHealthCheck
- BootstrapData
- 출처 : https://cluster-api.sigs.k8s.io/user/concepts.html#custom-resource-definitions-crds
Control Plane
- Machine기반
- pod 기반
- external : EKS, GKE, AKS 등과 같은 Cluster API가아닌 다른 시스템에 의해서도 제어가 가능
use case를 통한 이해
아래 personas를 기반으로 작성되었다.
- Managed Kubernetes
서비스 제공자에 의해 관리되어지는 K8s를 고객은 Control Plane(Master)부터 worker까지 모두 사용할수 있다. - kubernetes-as-a-service
서비스 제공자에 의해 관리되어지는 K8s를 고객은 Worker에 대한 관리영역을 가지게 되고 Control Plane(Master)는 서비스 제공자에 의해 관리되어지게 된다.
개인적으로는 kubespray의 경우 baremetal 상에 구동하기 좋고 하나의 환경을 지속적으로 관리하는 입장에서는 좀더 나은선택이 될것이라 판단되고 cluster-api의 경우 k8s를 대고객 서비스로 사용하는 경우 좋은 대안이 될것이라 판단된다.
cluster-api(clusterctl)의 원리
Installation and Usage
Prerequiste
먼저 아래의 준비사항이 필요하다.
- kubectl로 접근 가능한 kubernetes cluster (cluster-api.book에서는 kind 이용에 대한 메뉴얼을 제공한다.)
여기서는 K3s로 간단하게 배포된 환경을 이용해보도록 하겠다.
또 알아두어야할 것은 다음과 같다.
- 별도의 VM image를 사용한다. (kubernetes용 binary가 포함된.. 해서 image-builder를 이용해 별도로 생성해 upload 해야 한다.)
- Bastion enable 해야 control-plane 부터 worker에 ssh 접근이 가능하다.
(물론 수동으로 security group 부터 ssh key 등록등을 별도로 작업하면 되지만 Bastion을 사용하는것을 권장한다.)
workflow
다음과 같은 workflow를 가진다.
(해당 내용은 OpenStack Provider가 기준이되어 다른 provider의 경우 다소 다를수 있으나 큰 차이는 없으리라 생각된다.)
- Kubernetes(관리용)를 준비한다. (kind 나 k3s나 그외 앞서 보유한 Kubernetes도 무방)
- clusterctl 을 이용하여 앞서 준비한 Kubernetes(관리용) 에 provider에 맞는 cluster-api의 CRD들을 생성한다.
- 생성된 CRD를 활용해 provider의 machnie 및 실제 운영될 Kubernetes(배포될)를 생성하는 내용이 정의된 yaml 파일을 생성한다.
- 생성된 yaml 파일을 통해 kubernetes(관리용)에 cluster를 생성한다.
- 생성과 동시에 Kubernetes(배포될)가 배포될 provider에 Bastion(만약 선언되어 있다면)과 Control Plane이 생성된다.
- Control Plane이 배포가 완료되면 kubernetes(배포될)에 CNI를 설치한다. (설치전까지는 worker 배포가 안된다.)
- CNI 설치와 함께 worker가 배포되고 cluster-api를 통한 Kubernetes(배포될) 배포가 완료된다.
Install
- Kubernetes(관리용)을 준비한다.
quick-start 에 나온 kind를 사용해도 된다. 필자는 K3s를 사용했다.
- clusterctl download하고 Provider에 맞는 CRD 생성
clusterctl download하고 사용할수 있게 PATH에 등록된 경로에 복사한다.
curl -L https://github.com/kubernetes-sigs/cluster-api/releases/download/v0.3.14/clusterctl-linux-amd64 -o clusterctl
chmox +x clusterctl
sudo mv clusterctl /usr/local/bin/
자신이 배포하고자 하는 provider(AWS, GCP, Azure ... OpenStack 등)에 맞게 clusterctl 초기화를 수행한다.
(즉, 관련 CRD를 생성한다.)
clusterctl을 사용하여 init 명령을 수행하고 이를 통해 provider에 맞는 CRD들을 생성하자.
참고용으로 다음과 같은 provider가 지원되는것을 확인할수 있다.
[root@jacobbaek-deploy ~]# clusterctl config repositories NAME TYPE URL FILE cluster-api CoreProvider https://github.com/kubernetes-sigs/cluster-api/releases/latest/ core-components.yaml aws-eks BootstrapProvider https://github.com/kubernetes-sigs/cluster-api-provider-aws/releases/latest/ eks-bootstrap-components.yaml kubeadm BootstrapProvider https://github.com/kubernetes-sigs/cluster-api/releases/latest/ bootstrap-components.yaml talos BootstrapProvider https://github.com/talos-systems/cluster-api-bootstrap-provider-talos/releases/latest/ bootstrap-components.yaml aws-eks ControlPlaneProvider https://github.com/kubernetes-sigs/cluster-api-provider-aws/releases/latest/ eks-controlplane-components.yaml kubeadm ControlPlaneProvider https://github.com/kubernetes-sigs/cluster-api/releases/latest/ control-plane-components.yaml talos ControlPlaneProvider https://github.com/talos-systems/cluster-api-control-plane-provider-talos/releases/latest/ control-plane-components.yaml aws InfrastructureProvider https://github.com/kubernetes-sigs/cluster-api-provider-aws/releases/latest/ infrastructure-components.yaml azure InfrastructureProvider https://github.com/kubernetes-sigs/cluster-api-provider-azure/releases/latest/ infrastructure-components.yaml digitalocean InfrastructureProvider https://github.com/kubernetes-sigs/cluster-api-provider-digitalocean/releases/latest/ infrastructure-components.yaml docker InfrastructureProvider https://github.com/kubernetes-sigs/cluster-api/releases/latest/ infrastructure-components-development.yaml gcp InfrastructureProvider https://github.com/kubernetes-sigs/cluster-api-provider-gcp/releases/latest/ infrastructure-components.yaml metal3 InfrastructureProvider https://github.com/metal3-io/cluster-api-provider-metal3/releases/latest/ infrastructure-components.yaml openstack InfrastructureProvider https://github.com/kubernetes-sigs/cluster-api-provider-openstack/releases/latest/ infrastructure-components.yaml packet InfrastructureProvider https://github.com/kubernetes-sigs/cluster-api-provider-packet/releases/latest/ infrastructure-components.yaml sidero InfrastructureProvider https://github.com/talos-systems/sidero/releases/latest/ infrastructure-components.yaml vsphere InfrastructureProvider https://github.com/kubernetes-sigs/cluster-api-provider-vsphere/releases/latest/ infrastructure-components.yaml
jacob@jacob-laptop:~/CAPO-template$ clusterctl init --infrastructure openstack
Fetching providers
Installing cert-manager Version="v0.16.1"
Waiting for cert-manager to be available...
Installing Provider="cluster-api" Version="v0.3.14" TargetNamespace="capi-system"
Installing Provider="bootstrap-kubeadm" Version="v0.3.14" TargetNamespace="capi-kubeadm-bootstrap-system"
Installing Provider="control-plane-kubeadm" Version="v0.3.14" TargetNamespace="capi-kubeadm-control-plane-system"
Installing Provider="infrastructure-openstack" Version="v0.3.4" TargetNamespace="capo-system"
Your management cluster has been initialized successfully!
You can now create your first workload cluster by running the following:
clusterctl config cluster [name] --kubernetes-version [version] | kubectl apply -f -
참고로 아래와 같은 명령으로 debug를 수행해볼수 있다.
[root@jacobbaek-deploy ~]# clusterctl init --infrastructure openstack -v 10
동작된 환경을 확인해보면 다양한 namespace와 crd들이 생성된것을 확인할 수 있다.
(물론 앞서 지정했던 provider에 관한 crd들도 눈에 띄인다.)
[root@jacobbaek-deploy ~]# kubectl get ns
NAME STATUS AGE
capi-kubeadm-bootstrap-system Active 64m
capi-kubeadm-control-plane-system Active 64m
capi-system Active 64m
capi-webhook-system Active 64m
capo-system Active 63m
cert-manager Active 63m
default Active 2d13h
kube-node-lease Active 2d13h
kube-public Active 2d13h
kube-system Active 2d13h
rook-ceph Active 2d2h
[root@jacobbaek-deploy ~]# kubectl get crds -l cluster.x-k8s.io/provider=cluster-api
NAME CREATED AT
clusterresourcesetbindings.addons.cluster.x-k8s.io 2020-12-24T01:59:58Z
clusterresourcesets.addons.cluster.x-k8s.io 2020-12-24T01:59:58Z
clusters.cluster.x-k8s.io 2020-12-24T01:59:58Z
machinedeployments.cluster.x-k8s.io 2020-12-24T01:59:58Z
machinehealthchecks.cluster.x-k8s.io 2020-12-24T01:59:59Z
machinepools.exp.cluster.x-k8s.io 2020-12-24T01:59:59Z
machines.cluster.x-k8s.io 2020-12-24T01:59:59Z
machinesets.cluster.x-k8s.io 2020-12-24T02:00:00Z
[root@jacobbaek-deploy ~]# kubectl get crds -l cluster.x-k8s.io/provider=infrastructure-openstack
NAME CREATED AT
openstackclusters.infrastructure.cluster.x-k8s.io 2020-12-24T02:00:24Z
openstackmachines.infrastructure.cluster.x-k8s.io 2020-12-24T02:00:25Z
openstackmachinetemplates.infrastructure.cluster.x-k8s.io 2020-12-24T02:00:26Z
- provider에 생성될 Machine 정보 및 배포될 Kubernetes 정보가 작성된 yaml을 생성하자.
다음과 같은 명령을 통해 생성할 임의의 cluster에 맞는 yaml template 파일을 생성할수 있다.
[root@jacobbaek-deploy ~]# clusterctl config cluster capo-jacobcluster --kubernetes-version 1.18.3
Error: value for variables [OPENSTACK_CLOUD, OPENSTACK_CLOUD_CACERT_B64, OPENSTACK_CLOUD_PROVIDER_CONF_B64, OPENSTACK_CLOUD_YAML_B64, OPENSTACK_CONTROL_PLANE_MACHINE_FLAVOR, OPENSTACK_DNS_NAMESERVERS, OPENSTACK_FAILURE_DOMAIN, OPENSTACK_IMAGE_NAME, OPENSTACK_NODE_MACHINE_FLAVOR, OPENSTACK_SSH_KEY_NAME] is not set. Please set the value using os environment variables or the clusterctl config file
init만 한 환경에서는 위와 같은 환경변수가 추가로 필요하기에 다음과 같은 작업을 수행하기를 권장한다.
cluster-api에서는 다음과 같은 script을 제공한다.
[root@jacobbaek-deploy ~]# wget https://raw.githubusercontent.com/kubernetes-sigs/cluster-api-provider-openstack/master/templates/env.rc -O /tmp/env.rc
위 env.rc 명령을 bash로 수행해보면 clouds.yaml 뿐아니라 이를 parsing 할때 사용되는 yq command를 필요로 한다.
하여 다음과 같이 다운로드 및 설치한다.
[root@jacobbaek-deploy ~]# curl -L https://github.com/mikefarah/yq/releases/download/3.4.1/yq_linux_amd64 -o yq | chmod +x yq
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 638 100 638 0 0 4242 0 --:--:-- --:--:-- --:--:-- 4225
100 5934k 100 5934k 0 0 2075k 0 0:00:02 0:00:02 --:--:-- 3585k
[root@jacobbaek-deploy ~]# mv yq /usr/local/bin/
참고로 yq의 경우 버전에 따른 이슈가 있는듯하여 4.x나 2.x의 경우 실행시 문제들이 있었어서 3.x 최신버전을 사용했다.
이제 다음과 같은 환경변수를 로드하는 script을 수행한다.
[root@jacobbaek-deploy ~]# cat clouds.yaml
clouds:
openstack-cloud:
auth:
auth_url: http://openstack-cloud.openlab.com:5000/v3
project_name: jacobbaek
username: admin
password: xxxxxxxxxxxxxxxxxxx
user_domain_name: default
project_domain_name: default
region_name: RegionOne
[root@jacobbaek-deploy ~]# source /tmp/env.rc clouds.yaml openstack-cloud
위 스크립트를 통해 다음과 같은 환경변수가 지정되었음을 확인할 수 있다.
[root@jacobbaek-deploy ~]# export | grep OPENSTACK
declare -x OPENSTACK_CLOUD="openstack-cloud"
declare -x OPENSTACK_CLOUD_CACERT_B64="xxxx"
declare -x OPENSTACK_CLOUD_PROVIDER_CONF_B64="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
declare -x OPENSTACK_CLOUD_YAML_B64="xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"
[root@jacob-deploy clusterapi]# env | grep -E "CAPO|OPENSTACK"
OPENSTACK_CLOUD_PROVIDER_CONF_B64=W0dsb2JhbF0KYXV0aC11cmw9aHR0cDovL3BjdC0wMDIuaGFucGRhLmNvbTo1MDAwL3YzCnVzZXJuYW1lPSJhZG1pbiIKcGFzc3dvcmQ9ImxsbzhOVlNrQzNKa0VEYkVTSmc1bHlHalhQYWw0N1pOWk9Pcjh2amMiCnRlbmFudC1uYW1lPSJhZG1pbiIKZG9tYWluLW5hbWU9IkRlZmF1bHQiCnJlZ2lvbj0iUmVnaW9uT25lIgo=
OPENSTACK_CLOUD=kolla-openstack
OPENSTACK_CLOUD_CACERT_B64=Cg==
CAPO_CLOUD=kolla-openstack
OPENSTACK_CLOUD_YAML_B64=Y2xvdWRzOgogIGtvbGxhLW9wZW5zdGFjazoKICAgIGF1dGg6CiAgICAgIGF1dGhfdXJsOiBodHRwOi8vcGN0LTAwMi5oYW5wZGEuY29tOjUwMDAvdjMKICAgICAgcHJvamVjdF9uYW1lOiBhZG1pbgogICAgICB1c2VybmFtZTogYWRtaW4KICAgICAgcGFzc3dvcmQ6IGxsbzhOVlNrQzNKa0VEYkVTSmc1bHlHalhQYWw0N1pOWk9Pcjh2amMKICAgICAgdXNlcl9kb21haW5fbmFtZTogRGVmYXVsdAogICAgICBwcm9qZWN0X2RvbWFpbl9uYW1lOiBEZWZhdWx0CiAgICByZWdpb25fbmFtZTogUmVnaW9uT25lCg==
위 환경변수만으로는 부족하여 다음과 같은 정보를 추가로 설정해야 한다.
# The list of nameservers for OpenStack Subnet being created.
# Set this value when you need create a new network/subnet while the access through DNS is required.
export OPENSTACK_DNS_NAMESERVERS="8.8.8.8"
# FailureDomain is the failure domain the machine will be created in.
export OPENSTACK_FAILURE_DOMAIN="nova"
# The flavor reference for the flavor for your server instance.
export OPENSTACK_CONTROL_PLANE_MACHINE_FLAVOR="m1.medium"
# The flavor reference for the flavor for your server instance.
export OPENSTACK_NODE_MACHINE_FLAVOR="m1.medium"
# The name of the image to use for your server instance. If the RootVolume is specified, this will be ignored and use rootVolume directly.
export OPENSTACK_IMAGE_NAME="fcos33"
# The SSH key pair name
export OPENSTACK_SSH_KEY_NAME="jacobbaek-keypair"
참고로 아래 명령을 통해 어떤 환경변수 사용할수 있는지 확인해볼수 있다.
[root@jacob-deploy ~]# clusterctl config cluster --infrastructure openstack --list-variables capi-quickstart Variables: - CLUSTER_NAME - CONTROL_PLANE_MACHINE_COUNT - KUBERNETES_VERSION - NAMESPACE - OPENSTACK_CLOUD - OPENSTACK_CLOUD_CACERT_B64 - OPENSTACK_CLOUD_PROVIDER_CONF_B64 - OPENSTACK_CLOUD_YAML_B64 - OPENSTACK_CONTROL_PLANE_MACHINE_FLAVOR - OPENSTACK_DNS_NAMESERVERS - OPENSTACK_FAILURE_DOMAIN - OPENSTACK_IMAGE_NAME - OPENSTACK_NODE_MACHINE_FLAVOR - OPENSTACK_SSH_KEY_NAME - WORKER_MACHINE_COUNT
이제 환경변수 설정은 완료되었고 아래와 같은 명령을 통해 cluster template을 생성한다.
[root@jacobbaek-deploy ~]# clusterctl config cluster capi-quickstart --kubernetes-version v1.18.2 --control-plane-machine-count=3 --worker-machine-count=3 > capi-quickstart.yaml
생성된 capi-quickstart.yaml을 그대로 사용해도 되고 필요에 따라 ip 정보등을 변경하여 사용하면 된다.
NOTE
앞서 생성한 yaml 파일에 대한 명령어들을 script에 넣어놓았다. (각 Provider의 상황에 맞게 수정이필요하다.)
- 이제 Machine(kubernetes가 동작될) 및 Kubernetes(배포될)를 생성해보자.
앞서 만든 yaml 파일을 아래와 같이 Kubernetes(관리용)에 설치하자. jacob@jacob-laptop:~/CAPO-template$ kubectl apply -f capo-jacobcluster.yaml cluster.cluster.x-k8s.io/capo-jacobcluster created openstackcluster.infrastructure.cluster.x-k8s.io/capo-jacobcluster created kubeadmcontrolplane.controlplane.cluster.x-k8s.io/capo-jacobcluster-control-plane created openstackmachinetemplate.infrastructure.cluster.x-k8s.io/capo-jacobcluster-control-plane created machinedeployment.cluster.x-k8s.io/capo-jacobcluster-md-0 created openstackmachinetemplate.infrastructure.cluster.x-k8s.io/capo-jacobcluster-md-0 created kubeadmconfigtemplate.bootstrap.cluster.x-k8s.io/capo-jacobcluster-md-0 created secret/capo-jacobcluster-cloud-config created
- Bastion 및 Control-plane 배포
Bastion은 필수는 아니다 하지만 함께 구성하여 보안성을 조금이나마 높이는것이 좋을것이라 판단된다.
아래와 같이 machine이 control-plane만 provisioning 되고 나머지는 pending 상태이다.
jacob@jacob-laptop:~/workspaces/CAPO-template$ kubectl get machine
NAME PROVIDERID PHASE VERSION
capo-jacobcluster-md-0-6c5f74cb86-kpc85 Pending v1.18.2
capo-jacobcluster-md-0-6c5f74cb86-bz6vc Pending v1.18.2
capo-jacobcluster-control-plane-9wqht openstack:///ada85c09-66e4-4b05-9cee-d28ed3d450a7 Provisioning v1.18.2
- CNI 설치 및 worker 배포
Control-plane까지만 배포되고 worker 배포가 진행되지 않는다.
아래와 같이 CNI 설치가 필요하다.
CNI는 calico를 이용하도록 하였다.
참고로 calico.yaml을 다운로드 받아 설치한 이유는 앞선 yaml내에 선언된 cidr 주소를 임의로 변경하여 동일하게 맞춰주기 위함이다.
clusterctl get kubeconfig capo-jacobcluster > ~/.kube/capo.kubeconfig
curl https://docs.projectcalico.org/manifests/calico.yaml -O
kubectl --kubeconfig=/home/jacob/.kube/capo.kubeconfig create -f calico.yaml
- 배포완료
jacob@jacob-laptop:~/workspaces/CAPO-template$ kubectl get cluster
NAME PHASE
capo-jacobcluster Provisioned
jacob@jacob-laptop:~/workspaces/CAPO-template$ kubectl get openstackcluster
NAME CLUSTER READY NETWORK SUBNET BASTION
capo-jacobcluster capo-jacobcluster true 59a20138-df93-42ca-91fa-7e7e63f6c5f9 cd12d4d1-2802-48c3-ae0d-2bfcd6b309ba 203.245.42.85
jacob@jacob-laptop:~/workspaces/CAPO-template$ kubectl get machine
NAME PROVIDERID PHASE VERSION
capo-jacobcluster-md-0-6c5f74cb86-cnplg openstack:///c500f762-e516-4bd1-ac74-4fb183125760 Provisioning v1.18.2
capo-jacobcluster-md-0-6c5f74cb86-jkppk openstack:///96419b50-0311-4d27-8dc9-d911e6b2fe70 Provisioning v1.18.2
capo-jacobcluster-control-plane-28qww openstack:///681aa288-dff7-4905-b0aa-616e2c28a879 Running v1.18.2
uninstall
provider init 과정중에 이슈가 발생될 경우 삭제가 제대로 이루어지지 않았다.
하여 아래의 명령을 통해 삭제를 수행했다.
clusterctl delete --all --include-crd --include-namespace
# https://github.com/kubernetes-sigs/cluster-api/issues/3836#issuecomment-713859559
for crd in $(kubectl api-resources -o name | grep certmanager.k8s.io); do \
for resource in $(kubectl get -A -o name $crd); do \
echo "kubectl delete -A $resource"; \
done && \
echo "kubectl delete crd $crd"; \
done
kubectl delete crd certificaterequests.cert-manager.io
kubectl delete crd certificates.cert-manager.io
kubectl delete crd challenges.acme.cert-manager.io
kubectl delete crd clusterissuers.cert-manager.io
kubectl delete crd clusterresourcesetbindings.addons.cluster.x-k8s.io
kubectl delete crd clusterresourcesets.addons.cluster.x-k8s.io
kubectl delete crd clusters.cluster.x-k8s.io
kubectl delete crd issuers.cert-manager.io
kubectl delete crd kubeadmconfigs.bootstrap.cluster.x-k8s.io
kubectl delete crd kubeadmconfigtemplates.bootstrap.cluster.x-k8s.io
kubectl delete crd kubeadmcontrolplanes.controlplane.cluster.x-k8s.io
kubectl delete crd machinedeployments.cluster.x-k8s.io
kubectl delete crd machinehealthchecks.cluster.x-k8s.io
kubectl delete crd machinepools.exp.cluster.x-k8s.io
kubectl delete crd machines.cluster.x-k8s.io
kubectl delete crd machinesets.cluster.x-k8s.io
kubectl delete crd orders.acme.cert-manager.io
kubectl delete crd providers.clusterctl.cluster.x-k8s.io
kubectl delete crd openstackclusters.infrastructure.cluster.x-k8s.io
kubectl delete crd openstackmachines.infrastructure.cluster.x-k8s.io
kubectl delete crd openstackmachinetemplates.infrastructure.cluster.x-k8s.io
kubectl delete apiservice/v1alpha3.infrastructure.cluster.x-k8s.io
kubectl delete -A ns/cert-manager ns/cert-manager-test
혹 kubernetes (배포될) 설치과정중 이슈가 있을 경우 아래 명령을 참고하여 삭제를 수행한다.
(control-plane 배포과정중 이슈가 있을 경우 삭제가 제대로 이루어지지 않았었다.)
kubectl delete openstackcluster --all
kubectl delete machinedeployments --all
kubectl delete openstackmachinetemplates --all
kubectl delete kubeadmcontrolplanes --all
kubectl delete secret -l clusterctl.cluster.x-k8s.io/move=true
kubectl delete kubeadmconfigtemplate --all
kubectl delete cluster/capo-jacobcluster
kubectl delete -f capo-cluster.yaml
clusterctl delete --all --include-crd --include-namespace
kubectl delete ns/capi-webhook-system
kubectl delete -f https://github.com/jetstack/cert-manager/releases/download/v0.11.1/cert-manager.yaml
참고할 내용들
VM image만들기
제공되는 image-builder는 image-builder/images/capi 하위에서 make로 build가 가능하며
build 시 packer를 이용해 build가 되며 local에 kvm을 통해 VM build 과정을 수행한다.
참고로 아래와 같은 kubernetes 관련 package들이 사전에 설치되어진다.
- crictl
- kubeadm
wardroom (image-builder)
LoadBalancer 설정
LoabBalancer를 사용하거나 사용하지 않기 위해서는 배포될 yaml내에 아래 두 설정이 동시에 true 혹은 false로 설정되어야 한다.
managedAPIServerLoadBalancer: true
useOctavia: true
Bastion설정
bastion:
enabled: true
flavor: m1.medium
image: ubuntu-1804-capo
sshKeyName: jacobbaek-keypair
CAPD
cluster API Docker
cert-manager
참고사이트
- https://cluster-api.sigs.k8s.io/user/concepts.html#management-cluster
- https://tanzu.vmware.com/content/blog/the-what-and-the-why-of-the-cluster-api
- https://www.spectrocloud.com/blog/cluster-api-for-kubernetes-infrastructure-management/
- https://itnext.io/deep-dive-to-cluster-api-a0b4e792d57d
- https://events19.linuxfoundation.org/wp-content/uploads/2018/07/OSS-Japan-Cluster-API-Himani-Agrawal-Giri-Kuncoro.pdf
'Cloud > Kubernetes' 카테고리의 다른 글
Velero (0) | 2021.04.06 |
---|---|
ingress with subpath (0) | 2021.03.23 |
kubernetes ingress (0) | 2021.03.15 |
Longhorn (0) | 2021.03.13 |
K3s with calico (0) | 2021.03.05 |
- Total
- Today
- Yesterday
- minikube
- azure policy
- Jenkinsfile
- jenkins
- GateKeeper
- open policy agent
- ceph
- Terraform
- kubernetes install
- socket
- ansible
- aquasecurity
- macvlan
- minio
- mattermost
- kata container
- K3S
- OpenStack
- vmware openstack
- wsl2
- nginx-ingress
- hashicorp boundary
- Helm Chart
- openstack backup
- boundary ssh
- crashloopbackoff
- DevSecOps
- kubernetes
- metallb
- openstacksdk
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 | 31 |