[Kubernetes] 쿠버네티스 설치하기 (3) - Creating a cluster with kubeadm

Creating a cluster with kubeadm

Creating a cluster with kubeadm

Creating a minimum viable Kubernetes cluster that conforms to best practices. In fact, you can use kubeadm to set up a cluster that will pass the Kubernetes Conformance tests. kubeadm also supports other cluster lifecycle functions, such as bootstrap tokens and cluster upgrades.

The kubeadm tool is good if you need:

• A simple way for you to try out Kubernetes, possibly for the first time.
• A way for existing users to automate setting up a cluster and test their application.
• A building block in other ecosystem and/or installer tools with a larger scope.

You can install and use kubeadm on various machines: your laptop, a set of cloud servers, a Raspberry Pi, and more. Whether you're deploying into the cloud or on-premises, you can integrate kubeadm into provisioning systems such as Ansible or Terraform.

---

쿠버네티스 클러스터 환경을 구성하는데 kubeadm을 사용하면 좋은점을 설명하고 있는 것 같다.

다양한 시스템지원, 간단, 자동셋업, 테스트 하기도 좋으니 한번써봐라 이말이다.

클라우드 건 온 프레미스 환경이건 배포할 때 Ansible or Terraform 같은 프로비저닝 시스템과 통합가능 하단다.

프로비저닝 (provisioning)은 사용자의 요구에 맞게 시스템 자원을 할당, 배치, 배포해 두었다가 필요 시 시스템을 즉시 사용할 수 있는 상태로 미리 준비해 두는 것을 말한다. --- naver

 

 

---

Before you begin

To follow this guide, you need:

• One or more machines running a deb/rpm-compatible Linux OS; for example: Ubuntu or CentOS.
• 2 GiB or more of RAM per machine--any less leaves little room for your apps.
• At least 2 CPUs on the machine that you use as a control-plane node.
• Full network connectivity among all machines in the cluster. You can use either a public or a private network.

You also need to use a version of kubeadm that can deploy the version of Kubernetes that you want to use in your new cluster.

Kubernetes' version and version skew support policy applies to kubeadm as well as to Kubernetes overall. Check that policy to learn about what versions of Kubernetes and kubeadm are supported. This page is written for Kubernetes v1.19.

The kubeadm tool's overall feature state is General Availability (GA). Some sub-features are still under active development. The implementation of creating the cluster may change slightly as the tool evolves, but the overall implementation should be pretty stable.

---

사전 준비가 필요하다고 하고, public network 이건 private network 이건 가능하다고 한다.

난 VMware 환경으로 구성할 것이다.

버전도 맞추라고하고 이 페이지는 v1.19를 기준으로 한다고 한다. (1), (2)편을 쭉 따라 왔다면 자동적으로 v1.19일 것.

 

kubeadm tool은 GA 단계! 충분히 상용으로 이용가능하단다. 버전이 올라감에 따라 클러스터 환경을 구성하는데 변화가 있을 수도 있지만, 안정성을 위한 변화일 경우 변화를 받아들여야 할 것 같다.

 

 

---

Objectives

• Install a single control-plane Kubernetes cluster
• Install a Pod network on the cluster so that your Pods can talk to each other

---

이번 챕터의 목표다.

1. 쿠버네티스 클러스터 환경에, Node를 컨틀로할 수 있는 control-plane를 설치하자!

2. Pods 끼리의 통신가능하도록 Pod network를 설치하자!

 

 

---

Instructions

Installing kubeadm on your hosts

Note:

If you have already installed kubeadm, run apt-get update && apt-get upgrade or yum update to get the latest version of kubeadm.

When you upgrade, the kubelet restarts every few seconds as it waits in a crashloop for kubeadm to tell it what to do. This crashloop is expected and normal. After you initialize your control-plane, the kubelet runs normally.

---

우리는 이미 kubeadm을 설치하였다. 이 페이지에서 진행할 때 사용하는 버전(v.1.19)도 일치하니 넘어가도록 하자.

 

 

---

Initializing your control-plane node

The control-plane node is the machine where the control plane components run, including etcd (the cluster database) and the API Server (which the kubectl command line tool communicates with).

 

control-plane node란 왼쪽에 보이는 사진과같은 etcd, API Server 와 같은 컴포논트들이 실행되고 있는 공간이다.

- etcd

  key : value 형태로 저장되는 db 이다. 모든 클러스터 데이터가 저장된다고 한다.

일관성(데이터 형태 변화x), 고가용성(항상 사용가능)

 

- API Server

  쿠버네티스 API를 제공하는 컴포넌트 라고한다. kubectl을 이용하여 통신!

---

1. (Recommended) If you have plans to upgrade this single control-plane kubeadm cluster to high availability you should specify the --control-plane-endpoint to set the shared endpoint for all control-plane nodes. Such an endpoint can be either a DNS name or an IP address of a load-balancer.

---

한대의 control-palne를 구성하여 사용하고 있다가, 부하가 심해져 분산을 하고싶을 때 (고가용성) kubeadm init 를 실행할 때 --control-plane-endpoint ${DNS name or 로드밸런스 ip주소} 옵션을 주어서 설정 가능하다.

즉 L4와 같은 로드밸런스 기능을 탑재하고 있는 endpoint를 통해서 부하분산을 하고 싶으면 모든 control-plane에다가 위의 옵션을 사용하여 L4를 바라보게끔 해야하는 것 같다.

직접 해봐야 알겠지만 대략 이런 모습이 아닐까?

L4가 라운드로빈 방식이든, 해쉬 방식이든 트래픽을 분산하여 연결된 control-plane 들로 나누어 전송할텐데 어떠한 방식으로 서로 동기화가 진행할지 하긴 하다. 라우터처럼 동기화를 위한 프로토콜이 존재하는건가? 좀더 알아봐야할 것 같다.

 

---

2. Choose a Pod network add-on, and verify whether it requires any arguments to be passed to kubeadm init. Depending on which third-party provider you choose, you might need to set the --pod-network-cidr to a provider-specific value. See Installing a Pod network add-on.

---

pod들끼리 사용할 network cidr을 지정하라는 설명이다. 아래에도 나오겠지만 host network 와 겹쳐선안되니 172.16.0.0/24 B CLASS 사설망 대역을 쪼개서 입력할 것이다.

Pod network add-on의 설치에 관해선 아래에 따로 마련해놓았다.

 

 

---

3. (Optional) Since version 1.14, kubeadm tries to detect the container runtime on Linux by using a list of well known domain socket paths. To use different container runtime or if there are more than one installed on the provisioned node, specify the --cri-socket argument to kubeadm init. See Installing runtime.

---

옵션이라고 한다. kubeadm은 자동으로 container runtime을 찾는다고 한다. 하지만 명시적으로 --cir-socket ${socket 경로}를 통해 지정가능 하다는데 (Docker의 경우 : /var/run/docker.sock) 자동으로 찾을것임을 믿어의심치 않겠다. 건너뛰도록 하자.

 

---

4. (Optional) Unless otherwise specified, kubeadm uses the network interface associated with the default gateway to set the advertise address for this particular control-plane node's API server. To use a different network interface, specify the --apiserver-advertise-address=<ip-address> argument to kubeadm init. To deploy an IPv6 Kubernetes cluster using IPv6 addressing, you must specify an IPv6 address, for example --apiserver-advertise-address=fd00::101

---

--apiserver-adverties-address 옵션을 통해 control-plane의 컴포넌트 API server가 사용할 네트워크 인터페이스를 설정할 수 있다. 이 네트워크 인터페이스에는 본인 ipaddress, default-gateway 정보가 있어서 이를 API server가 이용하나 보다. 난 ens33 네트워크 인터페이스밖에 없으므로 건너뛸 것이다.

 

---

5. (Optional) Run kubeadm config images pull prior to kubeadm init to verify connectivity to the gcr.io container image registry.

---

gcr.io container image registry에 제대로 연결되는지 kubeadm init 치기전에 kubeadm config images pull를 쳐보라는데 제대로 연결됐으면 초기화가 제대로 될꺼고, 연결안됐으면 초기화가 안될거니 그냥 바로 kubeadm init를 하자 ㅎㅎ..

 

To initialize the control-plane node run:

kubeadm init <args>

위에 <args> 에다가 원하는 옵션을 설정가능하다.

 

 

---

Considerations about apiserver-advertise-address and ControlPlaneEndpoint

While --apiserver-advertise-address can be used to set the advertise address for this particular control-plane node's API server, --control-plane-endpoint can be used to set the shared endpoint for all control-plane nodes.

--control-plane-endpoint allows both IP addresses and DNS names that can map to IP addresses. Please contact your network administrator to evaluate possible solutions with respect to such mapping.

Here is an example mapping:

192.168.0.102 cluster-endpoint

Where 192.168.0.102 is the IP address of this node and cluster-endpoint is a custom DNS name that maps to this IP. This will allow you to pass --control-plane-endpoint=cluster-endpoint to kubeadm init and pass the same DNS name to kubeadm join. Later you can modify cluster-endpoint to point to the address of your load-balancer in an high availability scenario.

Turning a single control plane cluster created without --control-plane-endpoint into a highly available cluster is not supported by kubeadm.

---

--apiserver-advertise-address 옵션을 통해 control-plane API server의 ip를 꼭 설정하고

--contro-plane-endpoint를 통해서 로드밸런스 기능을 사용할 수 있다는 설명인데

이때 ip address 그대로 쓰지말고 /etc/hosts 에다가 (주소 도메인네임)으로 설정하고 DNS name을 이용하자라는 말이다. 그리고 지금은 single control plane를 만들꺼니까 고가용성기능은 일단 무시하자. 이후에 알아보자!

고가용성 관련 공식문서(kubernetes.io/docs/setup/production-environment/tools/kubeadm/high-availability/)

 

 

---

+ 2020-11-20 수정

이전 챕터에서 kubeadm init를 실행할 때 아무런 옵션도 주지않았는데 --pod-network-cidr 만큼은 입력해 주자.

calico를 설치할 때 설정값과 동일하게 172.16.0.0/24 를 넣어주자.

맨 아래 페이지 reset 과정을 거치고

kubeadm init --pod-network-cidr 172.16.0.0/24

그냥 진행해도 calico plugin을 설치할 때 자동적으로 pod-network가 calico.yaml에 의해 설정되는것 같은데, 혹시 모르니 입력하는 것이다. 이유를 알면 댓글을 부탁드립니다...

---

아무런 옵션을 주지 않았음에도 --apiserver-advertise-address 값은 default network interface가 선택되어 192.168.5.1로 자동설정 되었으니 확인만 하고 넘어가자

--pod-network-cidr 옵션은 이 바로뒤에 설명하고 있다.

 

root 유저가 아닌상태로 진행했다면 아래 커맨드를 실행시켜주자.

mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config

root유저가 사용하는 admin.conf 파일을 non-root user home 디렉토리로 이동시키는 명령어인 것 같다.

 

root 유저라면 아래와같은 커맨드를 실행시켜 KUBECONFIG의 경로를 환경설정해주자

export KUBECONFIG=/etc/kubernetes/admin.conf

또한 재부팅하면 환경설정이 날아가버리니 영구적으로 설정하기위해

/etc/profile의 맨 마지막에 똑같이 삽입해주자.

 

난 root 유저로 진행하겠다. 아마 튜토리얼을 쭉 따라하다가 마지막에는 non-root 유저로 진행해야할 것 같은데 일단은 배워야하니 root유저로 심플하게 ㄱㄱ

 

 

---

Installing a Pod network add-on

Caution:

This section contains important information about networking setup and deployment order. Read all of this advice carefully before proceeding.

You must deploy a Container Network Interface (CNI) based Pod network add-on so that your Pods can communicate with each other. Cluster DNS (CoreDNS) will not start up before a network is installed.

• Take care that your Pod network must not overlap with any of the host networks: you are likely to see problems if there is any overlap. (If you find a collision between your network plugin's preferred Pod network and some of your host networks, you should think of a suitable CIDR block to use instead, then use that during kubeadm init with --pod-network-cidr and as a replacement in your network plugin's YAML).

• By default, kubeadm sets up your cluster to use and enforce use of RBAC (role based access control). Make sure that your Pod network plugin supports RBAC, and so do any manifests that you use to deploy it.

• If you want to use IPv6--either dual-stack, or single-stack IPv6 only networking--for your cluster, make sure that your Pod network plugin supports IPv6. IPv6 support was added to CNI in v0.6.0.

---

Pod들 간의 통신에는 CNI라는 인터페이스를 기반으로하는 Pod network add-on이 필요하다.

CNI (Container Network Interface)란 컨테이너 사이의 네트워크 통신을 하기위한 인터페이스 같은데, 이를 implement 한 plugin을 설치해야하는 것 같다. 아마 모든 컨테이너들 사이의 통신은 이 plugin을 기반으로 동작할 것으로 추측

쿠버네티스 내부에 컨테이너의 이름으로 IP를 찾는용도로 CoreDNS를 사용하는 것 같은데 이 녀석도 CNI 기반으로 컨테이너들과 통신을 하는 것 같아서 plugin이 설치되어 있지 않으면 start up 되지 않을 것이란다..

plugin은 무엇을 사용할 지 좀있다가 살펴보자.

 

또한 주의점으로 Pod network 대역은 절대로 host network 대역과 겹치면 안된다는 것이다.

나의 host network는 192.168.5.0/24 대역을 사용하고 있는데 192.168.5.1 ~ 192.168.5.255, 총 255개의 ip를 사용할 수 있는데 host ip 주소의 맨 마지막 그러니까 이경우 192.168.5.255는 broadcast 용도로 사용하니 제외, 또한 192.168.5.254의 경우 내가 default router ip로 사용하고 있기 때문에 실직적으론 253개의 host ip를 사용할 수 있는 것이다.

 

또한 kubeadm은 RBAC( 역할 기반의 엑세스 컨트롤 )을 사용한다고 한다.

뭔가 노드간의 역할이 정해지고 그에따른 접근할 수 있는 기능이 다르거나 뭐 그런 것일까나.. 좀 더 알아봐야할듯

+ 아래에 apiserver에 연결된 node들의 list를 확인할 때 ROLE에 대한 내용이 보인다.

 

그 뒤 내용은 ipv6 관련인데 아직 까지는 필요없을듯 하다

 

 

---

아래의 커맨드를 실행하면 control-plane의 components들의 실행여부를 알 수 있는데

kubectl get pods --all-namespaces

현재 CNI plugin이 설치되어 있지 않아 대기중이다.

 

그럼 add-on 을 설치해볼건데 아래의 커맨드를 이용해서 적용하란다

kubectl apply -f <add-on.yaml>

이것만 덜렁 주고 뭘 설치해야하는지 알려주질 않아서 좀 찾아봤는데

CNI plugin 중에 Calico 라는 녀석이 kubeadm의 e2e를 테스트한 녀석이라고 한다.

* e2e란 End to End로서 종단간의 통신 테스트를 의미하는데 여기서는 Pod간의 Test를 말하는 것 같다.

 

그래서 눈에 띄는 Calico라는 add-on을 설치하여보자

 

어떻게 하라는건지 자세하게 안나와 있어서 내가 찾아봤다

Installing Addons

쿠버네티스 공식문서 Installing Addons 페이지에서

Calico 에 링크가 걸려있다.

About Calico

그러면 위의 CALICO 홈페이지로 넘어가는데 여기서 calico.yaml를 검색해보았다.

클릭! 최종적으로 아래의 페이지로 가자

Install Calico networking and network policy for on-premises deployments

 

좀 내리다보면 아래와같은 구간을 볼 수 있다.

위의 순서를 따라서 명령어를 실행하면 굿굿

 

curl https://docs.projectcalico.org/manifests/calico.yaml -O

다운로드 받았다.

순서 2번을 보면 기본적으로 네트워크 대역을 192.168.0.0/16을 사용하는데 제금 나의 host network 대역이 192.168.5.0/24 이기 때문에 포함되어버린다. 그래서 부분을 변경하여 적용할 것이다.

vi calico.yaml

에디터로 안으로 들어간 후 CALICO_IPV4POOL_CIDR 설정부분을 주석제거하고 수정하자!

/CALICO_IPV4POOL_CIDR

검색 후

주석되어 있는 이 부분을 해제 후 수정해주자

 

사설 IP대역(특수용도 주소)

종류	범위
A CLASS	10.0.0.0 ~ 10.255.255.255 / 8
B CLASS	172.16.0.0 ~ 172.31.255.255 / 12
C CLASS	192.168.0.0 ~ 192.168.255.255 / 16

사설 IP대역을 보고 나는 C CLASS, 192.168.0.0/16을 쪼개서 192.168.5.0/24 사용하고 있는데 하위에 포함되는 네트워크 대역이니 B CLASS 를 쪼갠 subnetwork, 172.16.0.0/24로 바꾸자!

2의8승 밖에 할당을 못하지만 네트워크구성을 확인하기 쉽도록 이렇게 설정하자

그리고 CNI add-on을 적용시키자!

kubectl apply -f calico.yaml

적용되면서 무엇인가 생성이 된다. (k8s가 뭔지 이 구간에서 검색을 했는데 쿠버네티스라고 한다ㅎㅎ..)

 

그럼 이제 CoreDNS가 제대로 실행 되었는지 확인!

kubectl get pods --all-namespaces

coredns 상태값 Running 확인, calico도 추가되고 Running 상태! 굿굿

 

이렇게 정상적으로 실행이된다면

ifconfig

이렇게 172.16.0.128로 할당된 tunl0 네트워크 인터페이스를 확인할 수 있다.

172.16.0.1 ~ 172.168.0.254 사이의 중간 값이라고 보면 되려나 ... 네트워크 대역을 다르게

10101100 (172) . 00010000 (16) . 00000000 (0). 00000000 (0) / 24 로 설정을 했었다.

그래서 마지막 8bits 만큼의 host ip를 할당할 수 있는데 이의 정중간 값, 즉 25번째 bit 값이 1로 바뀌었다.

10101100 (172) . 00010000 (16) . 00000000 (0). 10000000 (128)

 

---

Control plane node isolation

By default, your cluster will not schedule Pods on the control-plane node for security reasons. If you want to be able to schedule Pods on the control-plane node, for example for a single-machine Kubernetes cluster for development, run:

kubectl taint nodes --all node-role.kubernetes.io/master-

With output looking something like:

node "test-01" untainted 
taint "node-role.kubernetes.io/master:" not found 
taint "node-role.kubernetes.io/master:" not found

This will remove the node-role.kubernetes.io/master taint from any nodes that have it, including the control-plane node, meaning that the scheduler will then be able to schedule Pods everywhere.

---

스케쥴 포드에 관련된 내용같은데 아직 뭔지 잘 모르겠다. 일단은 사전지식만 얻고자 아래의 블로그를 보았다.

165. [Kubernetes] 쿠버네티스 스케줄러 및 스케줄링 동작 방식 (Taints, Toleration, Affinity, 커스텀 스케줄

이후에 관련되어서 내용이 나오면 그때 알아보도록 하자... 지금은 뭔소리인지 모르겠음

 

 

---

Joining your nodes

The nodes are where your workloads (containers and Pods, etc) run. To add new nodes to your cluster do the following for each machine:

• SSH to the machine
• Become root (e.g. sudo su -)
• Run the command that was output by kubeadm init. For example:
•  

kubeadm join --token <token> <control-plane-host>:<control-plane-port> --discovery-token-ca-cert-hash sha256:<hash>

---

이제 control-plane을 가지고 있는 서버가 Master 서버라고 불리는데 이 Master 서버로 각 Node들이 Join 해야한다.

kubeadm init 를 실행했을 때 맨아래쪽에 봤었던 kubeadm join 커맨드가 보였었는데 그 명령어를 실행하면 Join이 된다.

ex)

kubeadm join 192.168.5.1:6443 --token mf7zll.wu46xeb4zvaprjbs \
    --discovery-token-ca-cert-hash sha256:43706957df8a96e04fe57ab21c42396c64c1e88dca6ed9f692f712e64f0d1730​

 

 

---

If you do not have the token, you can get it by running the following command on the control-plane node:

kubeadm token list

---

 

위의 명령어를 실행하면 현재 생성되어있는 token 리스트가 출력된다.

최초 kubeadm init를 통해 생성된 token인데 TTL 만료시간이 55분 남았다 ... 또한 TOKEN 쪽 값을 보면 위에 kubeadm join의 옵션 --token 의 값과 일치하는 것을 볼 수 있다.

 

 

---

By default, tokens expire after 24 hours. If you are joining a node to the cluster after the current token has expired, you can create a new token by running the following command on the control-plane node:

kubeadm token create

---

그래서 토큰의 만료시간은 24시간이라고 한다. 나도 시간이 얼마 남지 않아서 token을 새로 만들고 싶었는데 위의 명령어를 입력하면 생성가능하다. ( 그럼 매번 24시간마다 새로 토큰을 발급하고 Node들이 새로 Join을 해야하는걸까? )

+ 2020-11-20 추가 - 토큰의 만료시간은 join에 대한 부분에만 적용하는 것 같다. 하루가 지나도 여전히 Master - Slave Node가 연결되서 통신이 잘된다.

WARNING이 뜨긴하는데 일단 토큰이 만들어졌다

 

 

---

If you don't have the value of --discovery-token-ca-cert-hash, you can get it by running the following command chain on the control-plane node:

openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | \
   openssl dgst -sha256 -hex | sed 's/^.* //'

---

자 그리고 kubeadm join 옵션중 마지막 하나인 --discovery-token-ca-cert-hash을 생성해보자

 

 

자 이제 Node 들에게 join 시킬 명령어를 만들어보자

kubeadm join --token <token> <control-plane-host>:<control-plane-port> --discovery-token-ca-cert-hash sha256:<hash>

에서

kubeadm join --token doxmen.yoygsgsmfhq17hlf 192.168.5.1:6443 --discovery-token-ca-cert-hash sha256:43706957df8a96e04fe57ab21c42396c64c1e88dca6ed9f692f712e64f0d1730

로 만들었다!

 

토큰을 생성할 때 아래의 명령어로 join 명령어를 자동으로 만들어준다고한다 (너무 편함..)

kubeadm token create --print-join-command

다음부턴 위의 커맨드를 이용하자.

(깔끔쓰)

 

그리고 아래의 커맨드로 현재 Master Node의 API Server에 붙은 Node 들을 확인할 수 있다.

kubectl get nodes

현재 노드들 연결상황은 kube-master 하나밖에 없다. ROLES는 master! 

 

 

---

Slave Node 구성

챕터(2) 의 Installing kubeadm, kubelet and kubectl 까지만 설치된 slave node에서 kubeadm join 을 해보자!

kubeadm join --token doxmen.yoygsgsmfhq17hlf 192.168.5.1:6443 --discovery-token-ca-cert-hash sha256:43706957df8a96e04fe57ab21c42396c64c1e88dca6ed9f692f712e64f0d1730

명령어로 join을 하려 했더니

이미 뭐가 존재한다면서 막 뭐라고한다. 내가 실수로 kubeadm init 까지 따라해버린 것이다...

 

kubeadm reset

위의 명령어를 입력하면 kubeadm init or kubeadm join 으로 셋팅된 값들이 reset 된다고 한다.

 reset을 하고 난 뒤 다시 kubeadm join을 하게되면!!!!

init로 kubelet을 실행시킨것처럼 join으로도 kubelet이 실행되면서 Master Node로 join이 되었다고 뜬다.

Certificate signing 요청을 control-plane이 설치되어있는 Master Node의 apiserver로 보내고 응답까지 잘 받았단다.

control-plane이 설치되어있는 Master Node로 가서 kubectl get nodes를 쳐보자!

 

kubectl get nodes

휴 성공이다 NAME 으로는 hostname으로 등록되었고, ROLES는 none이다.

또 버전이 .4 인데 kube-node1을 늦게 만들어서 그런지 그사이에 업데이트가 되버린것 같다. (아주 빠른 업데이트)

 

또한 Master Node에서 CNI를 구현한 calico add-on에 네트워크 설정을 172.16.0.0/24 했기 때문에 Slave Node의 tunl0에도 172.168.0.0 네트워크가 할당되었다!!

이제 이 Slave Node에서 생성되는 Pod들은 아마 172.16.0.1 ~ 이렇게 ip가 할당될 것 같다.

이후에 deployment 할 때 살펴보자

 

 

---

(Optional) Controlling your cluster from machines other than the control-plane node

In order to get a kubectl on some other computer (e.g. laptop) to talk to your cluster, you need to copy the administrator kubeconfig file from your control-plane node to your workstation like this:

scp root@<control-plane-host>:/etc/kubernetes/admin.conf .
kubectl --kubeconfig ./admin.conf get nodes

---

다른 컴퓨터에서( Node )에서 control-palne-host 즉 Master Node안에서 kubectl를 사용하는것과 같은 효과를 보고싶으면, 위의 명령어를 이용해 admin.conf를 받고 --kubeconfig 옵션을 사용하면 된다.

 

Slave Node 에서 kubectl get nodes 를 입력하면

보는 것처럼 admin.conf를 찾지 못해서 알 수가 없다고 한다. default가 localhost:8080 으로 쏘나보다 ㅎㅎ..

이것을 실제 Master Node의 ip와 port, 192.168.5.1:6443 으로만 가게해주면 되는 것 같은데, 그 설정파일 가져오자 .

 

혹여나 root 계정으로의 scp가 먹히지 않는다면 Master Node의 /etc/ssh/sshd.config 의 설정중에 PermitRootLogin 옵션을 주석제거하고 yes를 해보고 systemctl restart sshd를 하고 다시 해보자.

 

나는 /etc/kubernetes/로 바로 옮겼다. --kubeconfig 옵션을 안쓰고 사용하려고해서이다.

admin.conf 파일을 보니 server: 주소와 포트번호가 입력되어 있다.

 

다시 명령어 입력!

Slave Node 에서 kubectl을 사용하여 nodes들의 정보 확인!

 

 

---

(Optional) Proxying API Server to localhost

If you want to connect to the API Server from outside the cluster you can use kubectl proxy:

scp root@<control-plane-host>:/etc/kubernetes/admin.conf .
kubectl --kubeconfig ./admin.conf proxy

You can now access the API Server locally at http://localhost:8001/api/v1

---

아직 사용하는법은 안나왔지만 kubectl proxy도 위와같이 사용할 수 있다!

 

 

 

---

Clean up

If you used disposable servers for your cluster, for testing, you can switch those off and do no further clean up. You can use kubectl config delete-cluster to delete your local references to the cluster.

However, if you want to deprovision your cluster more cleanly, you should first drain the node and make sure that the node is empty, then deconfigure the node.

---

kubectl config delete-cluster 명령어를 이용하여 우리가 kubeadm을 사용해 만든 cluster 설정을 delete하는 내용인 것 같다.

cluster를 더 깔끔하게 지우고싶으면 drain the node를 하여 node를 비우고, node의 설정들을 제거해야하는 것 같다.

나중에 초기화해서 새로 세팅할 때 한번 사용해보자 ... 일단 keep

 

 

---

Remove the node

Talking to the control-plane node with the appropriate credentials, run:

kubectl drain <node name> --delete-local-data --force --ignore-daemonsets

Before removing the node, reset the state installed by kubeadm:

kubeadm reset

The reset process does not reset or clean up iptables rules or IPVS tables. If you wish to reset iptables, you must do so manually:

iptables -F && iptables -t nat -F && iptables -t mangle -F && iptables -X

If you want to reset the IPVS tables, you must run the following command:

ipvsadm -C

Now remove the node:

kubectl delete node <node name>

If you wish to start over simply run kubeadm init or kubeadm join with the appropriate arguments.

---

node를 삭제하는 과정을 설명하는 것 같은데 이것도 일단 keep

여기서 iptables와 ipvs에 관련해서는 로드밸런싱과 관련된 기능 때문에 reset 하는 것 같은데 아직 경험해보지 못해서 일단 넘어가도록 하겠다.

 

---

Clean up the control plane

You can use kubeadm reset on the control plane host to trigger a best-effort clean up.

See the kubeadm reset reference documentation for more information about this subcommand and its options.

---

control plane를 초기화 하는법은 간단하다. kubeadm reset!!

내가 모르고 Slave Node에 control plane를 설치해버려서 join을 못했을 때 사용한 명령어 이기도 하다.

 

 

---

Limitations

Cluster resilience

The cluster created here has a single control-plane node, with a single etcd database running on it. This means that if the control-plane node fails, your cluster may lose data and may need to be recreated from scratch.

Workarounds:

• Regularly back up etcd. The etcd data directory configured by kubeadm is at /var/lib/etcd on the control-plane node.

• Use multiple control-plane nodes. You can read Options for Highly Available topology to pick a cluster topology that provides high-availability.

---

single control-plane node와 single etcd database를 사용할 때 서버가 종료라도 되면 data가 날라가니 backup을 자주해줘라 하면서 /var/lib/etcd 디렉토리에 있다고 친절히 설명하고있다.

또한 고가용성을 위한 토폴로지 구성하는 법을 링크걸어주고 있다. 이는 이후에 반드시 해야하기 때문에 나중에 따로 또 작성하도록 하겠다!!!

 

 

 

---

ps. 휴.. 챕터3는 너무 길었다. 이틀에 걸쳐서 작성하였는데 아직가지도 모르는 용어와 동작원리가 너무 많다. 차근차근 알아가 보자.