1. 프로젝트 구성
- VirtualBox
- Ubuntu 20.04, Haproxy 2.0.18, Kubernetes 1.24.5
- Master node : 3대 // k8s-master-${노드 번호}
- Worker node : 3대 // k8s-worker-${노드 번호}
- Etcd : 3대 // etcd-${노드 번호}
- LB : 1대 // lb-01
1. 쿠버네티스 설치 전 환경 구성
K8S-BASS 이미지 생성
STORAGE : 100GI
Memory : 4 GI
Cpu : 4 core
Networt : host only network, nat
보안 구성 해제
firewall-cmd, Selinux
## firewalld 설치
sudo apt -y install firewalld
## disable 시킨다
sudo systemctl daemon-reload
sudo systemctl disable firewalld.service
## stop 시킨다
sudo systemctl stop firewalld.service
## 확인
sudo firewall-cmd –reload
swap 해제
스왑(swap)이란 물리 메모리(RAM)의 용량이 부족할 때 하드 디스크의 일부 공간을 메모리 처럼 사용하는 것이다.
이러한 동작은 swap in과 swap out으로 구분할 수 있다.
현재 메모리에 최대 100개의 프로세스가 올라갈수 있는데 이때, 101번째 프로세스가 추가로 올라가야 할 경우를 생각해보자.
swap out은 100개의 실행된 프로세스중 특정 프로세스를 잠시 Swap Partition으로 이동시켜 놓는 것을 말한다.
swap in은 스왑으로 이동했던 프로세스에서 이벤트가 올 경우, 다시 메모리 영역으로 이동시키는 것을 말한다.
쿠버네티스는 Pod를 생성할 때, 필요한 만큼의 리소스를 할당 받아서 사용하는 구조이다.
kubernetes는 메모리 Swap을 고려하지 않고 설계되었기 때문에 swap을 사용하지 않는다. container 자체가 process(=pod)이다.
## -a 현재 부팅된 상태에서 못 쓰게 한다.
sudo swapoff -a
## swap 라인을 아예 주석처리를 한다.
sudo vi /etc/fstab
시간 동기화
prometheus는 시간이 안 맞으면 잘 안돌아간다.
sudo apt -y install ntpsudo systemctl daemon-reload
sudo systemctl enable ntp
sudo systemctl restart ntp
## 상태 확인
sudo systemctl status ntp
● ntp.service - Network Time Service
Loaded: loaded (/lib/systemd/system/ntp.service; enabled; vendor preset: enabled)
Active: active (running)
sudo ntpq -p
network forward
주요 내용은 패킷 포워딩이 가능하도록 설정
sudo su -
cat /proc/sys/net/ipv4/ip_forward
echo '1' > /proc/sys/net/ipv4/ip_forward
cat /proc/sys/net/ipv4/ip_forward
도커 설치
docker를 설치하면 자동으로 containerd가 생긴다. 이것을 kubernetes에 연결한다.
-> 1.24.x 버전부터 이렇게 사용한다
sudo apt -y install apt-transport-https ca-certificates curl software-properties-common gnupg2
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key --keyring /etc/apt/trusted.gpg.d/docker.gpg add -
sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
tail /etc/apt/sources.list
sudo apt -y update
apt-cache policy docker-ce
apt-cache : 해당 패키지의 메타정보 조회
sudo apt-get -y install docker-ce
sudo docker version
cgroupfs > systemd
kubernetes는 cgroup을 사용하지 않고, cgroup의 상위 process인 systemd를 사용해야 한다.
cgroupfs이랑 systemd랑 차이는??
>> 어떤 방식으로 “컨테이너에 자원을 할당하는 cgroup을 관리하느냐”의 차이
Cgroupfs : 디렉터리 하위에서 리소스를 직접 매핑하는 구조를 가짐.
Systemd : slice > scope > service 단위의 계층적 구조를 만들어 각 네임스페이스에 자원을 격리시킴
이러한 구조는 /sys/fs/cgroup/system 하위의 파일 시스템의 계층 구조에서 확인이 가능함.
Cgroupfs와 systemd의 선호도 차이?
카카오 엔터프라이즈 ( 이하 카카오 )에서는 관리 정책의 차이 일뿐, 지금 당장의 시스템 성능에 영향을 주는 것은 아니라고 판단하여 계속 cgroupfs를 사용한다고 밝혔음.
>> 결과론 적으론 방법론적인 차이라고 생각함. 맘에 드는거 사용하는듯?
sudo docker info | grep -i cgroup
Cgroup Driver: cgroupfs
sudo vi /etc/docker/daemon.json
{
"exec-opts": ["native.cgroupdriver=systemd"], >> 여기서 systemd 사용
"log-driver": "json-file",
"log-opts": {
"max-size": "100m"
},
"storage-driver": "overlay2",
"storage-opts": [
"overlay2.override_kernel_check=true"
]
}
## 설정 적용
sudo mkdir -p /etc/systemd/system/docker.service.d
sudo systemctl daemon-reload
sudo systemctl enable docker
sudo systemctl restart docker
sudo systemctl status docker
● docker.service - Docker Application Container Engine
Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
Active: active (running)
>> 쿠버네티스 클러스터에 연결되기 전에는 kubelet은 동작하지 않으니 안심하자
>> containerd는 실행이 되어있어야함.
sudo systemctl restart containerd.service
sudo systemctl status containerd.service
## 확인
sudo docker info | grep -i cgroup
>> Cgroup Driver: systemd
kubernetes tool 설치
kubeadm : bootstrap, init(초기화), worker node JOIN, engine 자체의 upgrade
kubectl : kubernetes CLI
kubelet : process(daemon) 항상 살아있어야 한다.
## repository 등록
curl -s https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
cat <<EOF | sudo tee /etc/apt/sources.list.d/kubernetes.list
> deb https://apt.kubernetes.io/ kubernetes-xenial main
> EOF
sudo apt -y update
sudo apt-cache policy kubeadm
apt-cache : 해당 패키지의 메타정보 조회
## 버전 체크
sudo apt-cache policy kubeadm | grep 1.24
## 설치
sudo apt -y install kubeadm=1.24.5-00 kubelet=1.24.5-00 kubectl=1.24.5-00
## 설치 되었는지 확인
sudo apt list | grep kubernetes
kubeadm/kubernetes-xenial 1.25.2-00 amd64 [upgradable from: 1.24.5-00]
kubectl/kubernetes-xenial 1.25.2-00 amd64 [upgradable from: 1.24.5-00]
kubelet/kubernetes-xenial 1.25.2-00 amd64 [upgradable from: 1.24.5-00]
## 항상 살아있을 수 있게 설정
sudo systemctl daemon-reload
sudo systemctl enable --now kubelet
sudo vi /etc/hosts
모든 master, node에서 ssh 접속 해서 키 얻어놓기
ssh k8s-node1
ssh k8s-node2
cat .ssh/known_hosts
master, worker 노드 각 3개씩 복제.
Master node의 로드밸런싱을 위한 lb 노드 구성. // control-plane-endpoint로 사용
Lb-01 : 192.168.56.110
Sudo apt install -y haporxy
/etc/haproxy/haproxy.cfg 밑에 기입
frontend kubernetes-master-lb
bind 0.0.0.0:26443 << 여기가 나중에 컨트롤 플레인 앤드포인트로 설정됨.
option tcplog
mode tcp
default_backend kubernetes-master-nodes
backend kubernetes-master-nodes
mode tcp
balance roundrobin
option tcp-check
option tcplog
server node1 k8s-master-01:6443 check
server node2 k8s-master-02:6443 check
server node3 k8s-master-03:6443 check
lb 설정 끝
master node에서 실행
cd /etc/containerd/
kevin@k8s-master:/etc/containerd$ sudo mv config.toml config.toml.org
## 재시작
sudo systemctl restart containerd.service
sudo systemctl restart kubelet
# 쿠버네티스 사용을 위한 권한 부여
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
master-node-join
kubeadm control-plane-endpoint:port --token 클러스터 조인 토큰\
--discovery-token-ca-cert-hash 인증서\
--control-plane
--certificate-key master 노드용 인증키
Worker node join
kubeadm control-plane-endpoint:port --token 클러스터 조인 토큰\
--discovery-token-ca-cert-hash 인증서
: CNI ( Container network interface ) 설치 // CALICO
kubectl apply -f calcurl -O https://docs.projectcalico.org/manifests/calico.yamlico.yaml
kubectl apply -f calico.yaml
CNI를 별도로 설치해야하는 이유??
일단 쿠버네티스에서도 default cni가 존재하지만 크로스 노드 네트워크, 네트워크 정책 선언과 같은 기능은 지원하지 않는다고함.
그래서 calico, flannel과 같은 CNI를 설치해야 노드간 통신이 가능하다고 함.
# node exporter, Prometheus , 그라파나 설치
## mater, node1, node2에서 시간 동기화
sudo apt -y install rdate
sudo rdate -s time.bora.net
date
## git clone
git clone https://github.com/brayanlee/k8s-prometheus.git
cd k8s-prometheus/
## Prometheus
kubectl create namespace monitoring
kubectl create -f prometheus/prometheus-ConfigMap.yaml
kubectl create -f prometheus/prometheus-ClusterRoleBinding.yaml
kubectl create -f prometheus/prometheus-ClusterRole.yaml
kubectl create -f prometheus/prometheus-Deployment.yaml
kubectl create -f prometheus/prometheus-Service.yaml
kubectl create -f prometheus/prometheus-DaemonSet-nodeexporter.yaml
## kube-state
kubectl create -f kube-state/kube-state-ClusterRoleBinding.yaml
kubectl create -f kube-state/kube-state-ClusterRole.yaml
kubectl create -f kube-state/kube-state-ServiceAccount.yaml
kubectl create -f kube-state/kube-state-Deployment.yaml
kubectl create -f kube-state/kube-state-Service.yaml
## grafana
kubectl create -f grafana/grafana-Deployment.yaml
kubectl create -f grafana/grafana-Service.yaml
쿠버네티스 환경 구성을 위한 Kubeadm config파일 설정
명령어
Sudo kubeadm init –config ${ config file } –upload-certs
By adding the flag --upload-certs to kubeadm init you can temporary upload the control-plane certificates to a Secret in the cluster.
>> Control-plane인증서를 클러스터의 Secret에 임시로 업로드할 수 있습니다.
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration // 클러스터 구성
// ClusterConfiguration : etcd, kube-apiserver, kube-scheduler, kube-controller-manager 구성함
kubernetesVersion: "1.24.5" // 버전
controlPlaneEndpoint: "lb-01:26443"
// 로드밸런서 기반의 control plane을 위한 lb ip:port
// lb-01에 haproxy 기반의 master node들을 로드밸런싱을 적용함
etcd:
external:
endpoints:
- https://etcd-01:2379 // 외부 etcd 주소 1
- https://etcd-02:2379 // 외부 etcd 주소 2
- https://etcd-03:2379 // 외부 etcd 주소 3
caFile: /etc/kubernetes/pki/etcd/ca.crt
certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt
keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key
· ca.crt : 쿠버네티스 root CA 인증서, 여러 다른 인증서를 이를 기반으로 발급
· apiserver-etcd-client.crt : apiserver가 etcd와 연결하기 위해 사용하는 키
· apiserver-etcd-client.key : apiserver-etcd-client.crt와 대응되는 비밀 키
networking:
podSubnet: 10.96.0.0/12 // podSubnet 파드의 cidr를 구성함
---
apiVersion: kubeadm.k8s.io/v1beta3
kind: InitConfiguration
// kubeadm init의 런타임에 적용되는 정보이다.
localAPIEndpoint:
// apiserver의 endpoint를 기입.
// ClusterConfiguration 에도 비슷한 설정이 있지만, 해당 설정이랑은 다르다.
// 쿠버네티스 클러스터를 구성하게되면, api서버를 자동으로 찾게되는데, 찾는게 불가능하면 아래의 ip:port로 api server를 설정한다.
advertiseAddress: 192.168.56.111
bindPort: 6443
아래 독스 참조
https://kubernetes.io/docs/reference/config-api/kubeadm-config.v1beta3/
Kubeadm에서 쿠버네티스를 설치하는 과정
쿠버네티스의 설치 과정을 요약해보면
1. 초기화
2. 환경 점검
3. 인증키 발급
4. 쿠버네티스 마스터 노드의 컴포넌트 배포
5. 설정이 config map에 저장됨.
6. 시스템 관리를 위한 토큰, RBAC을 구성
7. 네트워크 운영에 필요한 CNI ( CALICO, FLANNEL, WEAVE 등 ) 설치
// 마스터 노드에는 칼리코 컨트롤러, IPAM 플러그인, CALICOCTL, CONFD가 설정되고 칼리코 설정정보가 ETCD에 저장
8. 워커노드 조인 시 해당 노드에 CALICO POD 배포 ( Bird, felix )
kubeadm을 사용해야하는 이유
· kubelet에서 API 서버 인증서를 인증시 사용하는 클라이언트 인증서
· API 서버가 kubelet과 통신하기 위한 kubelet 서버 인증서
· API 서버 엔드포인트를 위한 서버 인증서
· API 서버에 클러스터 관리자 인증을 위한 클라이언트 인증서
· API 서버에서 kubelet과 통신을 위한 클라이언트 인증서
· API 서버에서 etcd 간의 통신을 위한 클라이언트 인증서
· 컨트롤러 매니저와 API 서버 간의 통신을 위한 클라이언트 인증서/kubeconfig
· 스케줄러와 API 서버간 통신을 위한 클라이언트 인증서/kubeconfig
· front-proxy를 위한 클라이언트와 서버 인증서
·
쿠버네티스를 구성하기 위한 인증서와 인증키는 이렇게 많다. 이런 것을 보다 쉽게 관리하고 교환하는 과정을 kubeadm api를 사용하여 구성이 가능하다.
위에서 1~6을 자동화해줌.
시작!
[init] Using Kubernetes version: v1.24.5
============================== 환경 점검 ===============================
[preflight] Running pre-flight checks
> 체크 시작
[preflight] Pulling images required for setting up a Kubernetes cluster
> 쿠버네티스 이미지 다운
[preflight] This might take a minute or two, depending on the speed of your internet connection
> 인터넷 점검
[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'
> 쿠버 adm config 이미지 다운
=======================================================================
========================= 인증키 발급 =========================
[certs] Using certificateDir folder "/etc/kubernetes/pki"
> 쿠버네티스 인증 폴더로 "/etc/kubernetes/pki" 사용함
[certs] Generating "ca" certificate and key
> 쿠버네티스 ca 인증서, 키 생성
[certs] Generating "apiserver" certificate and key
> 쿠버네티스 apiserver 인증서, 키 생성
[certs] apiserver serving cert is signed for DNS names [k8s-master-01 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local lb-01] and IPs [10.96.0.1 10.0.2.111]
> 쿠버네티스 config의 pod subnet을 바탕으로 ip 대역 생성
[certs] Generating "apiserver-kubelet-client" certificate and key
> 쿠버네티스 apiserver-kubelet-client 인증서, 키 생성
[certs] Generating "front-proxy-ca" certificate and key
> 쿠버네티스 front-proxy-ca 인증서, 키 생성
[certs] Generating "front-proxy-client" certificate and key
> 쿠버네티스 front-proxy-client 인증서, 키 생성
--- 외부 etcd 구성이므로 내부 etcd 구성은 스킵함. ---
[certs] External etcd mode: Skipping etcd/ca certificate authority generation
[certs] External etcd mode: Skipping etcd/server certificate generation
[certs] External etcd mode: Skipping etcd/peer certificate generation
[certs] External etcd mode: Skipping etcd/healthcheck-client certificate generation
[certs] External etcd mode: Skipping apiserver-etcd-client certificate generation
----------- 여기 까지 스킵 ------------
[certs] Generating "sa" key and public key
> sa : service account
· 서비스 어카운트는 클러스터 네임스페이스를 체계적으로 권한을 관리하기 위한 오브젝트
· 네임 스페이스에 속하는 오브젝트 << RBAC
=======================================================================
================================ 환경 구성 =============================
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
W1006 20:01:36.116957 9853 endpoint.go:57] [endpoint] WARNING: port specified in controlPlaneEndpoint overrides bindPort in the controlplane address
[kubeconfig] Writing "admin.conf" kubeconfig file
W1006 20:01:36.358279 9853 endpoint.go:57] [endpoint] WARNING: port specified in controlPlaneEndpoint overrides bindPort in the controlplane address
[kubeconfig] Writing "kubelet.conf" kubeconfig file
W1006 20:01:36.414213 9853 endpoint.go:57] [endpoint] WARNING: port specified in controlPlaneEndpoint overrides bindPort in the controlplane address
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
W1006 20:01:36.554039 9853 endpoint.go:57] [endpoint] WARNING: port specified in controlPlaneEndpoint overrides bindPort in the controlplane address
[kubeconfig] Writing "scheduler.conf" kubeconfig file
==================================================================
================= kubelet이 동작하며 각종 static pod를 생성함 =================
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Starting the kubelet
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
[control-plane] Creating static Pod manifest for "kube-apiserver"
[control-plane] Creating static Pod manifest for "kube-controller-manager"
[control-plane] Creating static Pod manifest for "kube-scheduler"
// 여기서 static Pod란?
// API 서버 없이 특정 노드의 kubelet 데몬에 의해 관리되는 파드. 이 스태틱 파드의 정의는 서버 내 특정 디렉토리에
// yaml 형태로 존재한다.
[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
// 각종 static pod가 올라오기를 기다림. static pod의 yaml은 "/etc/kubernetes/manifests" 여기 있음
[apiclient] All control plane components are healthy after 5.022631 seconds
======================================================================================
====================== 설정 파일들이 CONFIG MAP에 저장됨. ===========================
[upload-config] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config" in namespace kube-system with the configuration for the kubelets in the cluster
> 컨피그맵에 Kubelet에 대한 정보가 저장됨.
[upload-certs] Storing the certificates in Secret "kubeadm-certs" in the "kube-system" Namespace
[upload-certs] Using certificate key:
f2d8a37cf83d092c1afa0b7202102760b15df621bd6de08c0afbfc4b3277f443
> 토큰 발급
========================= 컨트롤 플레인으로 선정됨 =======================
[mark-control-plane] Marking the node k8s-master-01 as control-plane by adding the labels: [node-role.kubernetes.io/control-plane node.kubernetes.io/exclude-from-external-load-balancers]
[mark-control-plane] Marking the node k8s-master-01 as control-plane by adding the taints [node-role.kubernetes.io/master:NoSchedule node-role.kubernetes.io/control-plane:NoSchedule]
=======================================================================
================== 시스템 관리를 위한 토큰, RBAC을 구성함 ================
[bootstrap-token] Using token: guappu.kqhjxk9k8xahnlz3
[bootstrap-token] Configuring bootstrap tokens, cluster-info ConfigMap, RBAC Roles
[bootstrap-token] Configured RBAC rules to allow Node Bootstrap tokens to get nodes
[bootstrap-token] Configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstrap-token] Configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstrap-token] Configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[bootstrap-token] Creating the "cluster-info" ConfigMap in the "kube-public" namespace
[kubelet-finalize] Updating "/etc/kubernetes/kubelet.conf" to point to a rotatable kubelet client certificate and key
=======================================================================
============================ 추가적인 구성 적용 ==========================
[addons] Applied essential addon: CoreDNS
W1006 20:01:45.971582 9853 endpoint.go:57] [endpoint] WARNING: port specified in controlPlaneEndpoint overrides bindPort in the controlplane address
[addons] Applied essential addon: kube-proxy
=======================================================================
Your Kubernetes control-plane has initialized successfully!
~~~~ control-plane 토큰 및 워커 노드 토큰이 발급됨 ~~~~
--------------- 기본 클러스터 사전 구성은 스킵함. -----------------
사전 구성.
1. Control plane 구성을 위한 master node 3개
2. Data plane 구성을 위한 worker node 3개
3. Master node load-balancer를 위한 lb node 1개
4. 모든 노드의 nat은 달라야함.
5. /etc/hosts에 모든 노드의 정보 등록.
6. Swap, firewall, containerd, kubelet, docker 등 환경 구성
K8s-Master-01 에서 시작함.
일단 /etc/contarinerd 에 config.taml.org 설정이 되어있는지 확인.
Sudo systemctl restart containerd
Sudo systemctl restart kubelet
1. Kubeadm init을 위한 설정
vi config.yaml 파일 생성
apiVersion: kubeadm.k8s.io/v1beta3
kind: ClusterConfiguration
kubernetesVersion: "1.24.5"
controlPlaneEndpoint: "lb-01:26443"
etcd:
external:
endpoints:
- https://etcd-01:2379
- https://etcd-02:2379
- https://etcd-03:2379
caFile: /etc/kubernetes/pki/etcd/ca.crt
certFile: /etc/kubernetes/pki/apiserver-etcd-client.crt
keyFile: /etc/kubernetes/pki/apiserver-etcd-client.key
networking:
podSubnet: 10.96.0.0/12
---
apiVersion: kubeadm.k8s.io/v1beta3
kind: InitConfiguration
localAPIEndpoint:
advertiseAddress: 192.168.56.111
bindPort: 6443
etcd에서 받은 키 쿠버네티스 환경 설정 디렉터리에 업로드
mkdir -p /etc/kubernetes/pki/etcd/
cp /home/kakao/pki/etc/etcd/pki/ca.crt /etc/kubernetes/pki/etcd/
cp /home/kakao/pki/etc/etcd/pki/ca.key /etc/kubernetes/pki/etcd/
cp /home/kakao/pki/etc/etcd/pki/apiserver-etcd-client.key /etc/kubernetes/pki/
cp /home/kakao/pki/etc/etcd/pki/apiserver-etcd-client.crt /etc/kubernetes/pki/
kubeadm init 시작
sudo kubeadm init --config configv2.yaml --upload-certs
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
권한 설정 후
Calico 설치
curl -O https://docs.projectcalico.org/manifests/calico.yaml
kubectl apply -f calico.yaml
kubectl get po -A
실행 후 칼리코 pod, coredns 가 올라왔는지 확인.
모두 running 상태를 확인하고 다음 작업을 시작함.
1. Worker 노드로 설정할 곳으로 이동함.
각자의 토큰을 입력한다.
sudo kubeadm join lb-01:26443 --token 9trdpq.g2dfj0ek176z4ldz \
--discovery-token-ca-cert-hash sha256:540f9bdc3f17cab01cc1c54e4d32e9e4b7db46bfb883434a325e5ef71c76bc28
완료된 후 master node로 이동해서 pod 생성을 본다.
여기서 pod가 올라오지 않으면 문제가 있는 것이다.
Calico가 제대로 설치되어 있는지 확인한다. << 혹은 다른 CNI를 설치한다.
혹은 외부 ETCD를 구성하였다면, ETCD를 초기화하고 다시 진행해본다.
기존에 남아 있던 데이터로 인한 오류가 발생할 수 있다.
이 작업을 원하는 worker node 수 만큼 반복한다.
1. Control-plane 구성
아까 HA PROXY를 구성할 때 기입한 ip를 가진 노드로 이동한다.
sudo kubeadm join lb-01:26443 --token 9trdpq.g2dfj0ek176z4ldz \
--discovery-token-ca-cert-hash sha256:540f9bdc3f17cab01cc1c54e4d32e9e4b7db46bfb883434a325e5ef71c76bc28 \
--control-plane --certificate-key 754ddfd3061a7b902da7aa10539f8c30fa5973a37890ec06deb702ed00e6974b
이번엔 control plane 설정을 적용해야하므로, 인증서 값이 주가되었다.
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
권한을 설정하고
Static pod와 칼리코가 제대로 전파되었는지 확인한다.
이 작업도 lb에 적어둔 master node의 수 만큼 반복한다.
Pod와 노드가 정상적인 경우에 그라파나 설정을 준비한다.
1. Node exporter, prometheus 설치 // 그라파나는 다른 모니터링 서버에서 개별로 구축
## git clone
git clone https://github.com/brayanlee/k8s-prometheus.git
cd k8s-prometheus/
## Prometheus
kubectl create namespace monitoring
kubectl create -f prometheus/prometheus-ConfigMap.yaml
kubectl create -f prometheus/prometheus-ClusterRoleBinding.yaml
kubectl create -f prometheus/prometheus-ClusterRole.yaml
kubectl create -f prometheus/prometheus-Deployment.yaml
kubectl create -f prometheus/prometheus-Service.yaml
kubectl create -f prometheus/prometheus-DaemonSet-nodeexporter.yaml
## kube-state
kubectl create -f kube-state/kube-state-ClusterRoleBinding.yaml
kubectl create -f kube-state/kube-state-ClusterRole.yaml
kubectl create -f kube-state/kube-state-ServiceAccount.yaml
kubectl create -f kube-state/kube-state-Deployment.yaml
kubectl create -f kube-state/kube-state-Service.yaml
워커 노드에 node-exporter 가 제대로 설치됐는지 확인하고 다음 작업으로 넘어간다.
프로메테우스는 노드포트 서비스를 이용하여 배포되었다.
노드포트는 노드IP:포트 로 이동하면 해당 노드포트 서비스로 이동하게 된다.
해당 노드 포트 서비스에서 각 파드로 요청을 포워딩해준다.
모니터링 서버 : http://192.168.56.140:3000/
워커 노드에 node-exporter 가 제대로 설치됐는지 확인하고 다음 작업으로 넘어간다.
프로메테우스는 노드포트 서비스를 이용하여 배포되었다.
노드포트는 노드IP:포트 로 이동하면 해당 노드포트 서비스로 이동하게 된다.
해당 노드 포트 서비스에서 각 파드로 요청을 포워딩해준다.
모니터링 서버 : http://192.168.56.140:3000/
모니터링 서버에서 데이터 소스 입력.
소스 입력후 IMPORT 선택
이쁜 대시보드를 선택해 Load 후 데이터소스 입력 후 적용
Wireshark를 이용한 haproxy 로드밸런싱 확인
트러블 슈팅
1. LoadBalancer type의 서비스를 배포시 pending에서 넘어가지 않는 상태
- 쿠버네티스에서 pending에서 넘어가지 않으면 쿠버네티스에 자체 로드밸런서가 존재하지 않기 때문이라 한다.
- 이에 있어서 metalLB를 설치해 로드밸런서 타입으로 배포를 해야한다.
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.9.3/manifests/namespace.yaml
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.9.3/manifests/metallb.yaml
kubectl create secret generic -n metallb-system memberlist --from-literal=secretkey="$(openssl rand -base64 128)"
metalLB config
apiVersion: v1
kind: ConfigMap
metadata:
namespace: metallb-system
name: config
data:
config: |
address-pools:
- name: default
protocol: layer2
addresses:
- 192.168.56.123-192.168.56.121
Kubectl apply -f metallb-config.yaml
2.
Kubectl 권한이 없음. 해당 파일에 권한을 부여해야함.
Sudo chmod 755 /etc/kubernetes/admin.conf
2. 인증서 설정
Config 설정을 다시 해주어야함.
unset KUBECONFIG
export KUBECONFIG=/etc/kubernetes/admin.conf
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
1.
처음에 kubeadm 을 사용해 쿠버네티스 클러스터를 구성할 때 각종 인증키를 쿠버네티스에 등록하지 않아서 생기는 문제이다.
Sudo kubeadm init –-config configv2.yaml –-upload-certs
–-upload-certs 를 추가하여 각종 인증서와 인증키를 쿠버네티스 configmap에 업로드하자
2. Kube-system의 파드 중 Coredns가 올라오지 않는 상태
각 노드를 인식하지 못해서 생기는 문제이다.
쿠버네티스에도 기본적인 cni는 있는데, 크로스 노드 네트워킹, 네트워크 정책 설정과 같은 고급 기능은 지원하지 않는다. 이에 있어서 칼리코, 플란넬과 같은 CNI를 새로 설치해주어야한다.
3. 칼리코 노드 활성화 안됨.
Nat ip가 같아서 생기는 오류이다.
>> 클러스터끼리 다른 nat ip를 할당해준다.
참고
https://itecnote.com/tecnote/kubernetes-calico-node-crashloopbackoff/
1. LoadBalancer type의 서비스를 배포시 pending에서 넘어가지 않는 상태
- 쿠버네티스에서 pending에서 넘어가지 않으면 쿠버네티스에 자체 로드밸런서가 존재하지 않기 때문이라 한다.
- 이에 있어서 metalLB를 설치해 로드밸런서 타입으로 배포를 해야한다.
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.9.3/manifests/namespace.yaml
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.9.3/manifests/metallb.yaml
kubectl create secret generic -n metallb-system memberlist --from-literal=secretkey="$(openssl rand -base64 128)"
metalLB config
apiVersion: v1
kind: ConfigMap
metadata:
namespace: metallb-system
name: config
data:
config: |
address-pools:
- name: default
protocol: layer2
addresses:
- 192.168.56.123-192.168.56.121
Kubectl apply -f metallb-config.yaml
2.
Kubectl 권한이 없음. 해당 파일에 권한을 부여해야함.
Sudo chmod 755 /etc/kubernetes/admin.conf
2. 인증서 설정
Config 설정을 다시 해주어야함.
unset KUBECONFIG
export KUBECONFIG=/etc/kubernetes/admin.conf
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
1.
처음에 kubeadm 을 사용해 쿠버네티스 클러스터를 구성할 때 각종 인증키를 쿠버네티스에 등록하지 않아서 생기는 문제이다.
Sudo kubeadm init –-config configv2.yaml –-upload-certs
–-upload-certs 를 추가하여 각종 인증서와 인증키를 쿠버네티스 configmap에 업로드하자
2. Kube-system의 파드 중 Coredns가 올라오지 않는 상태
각 노드를 인식하지 못해서 생기는 문제이다.
쿠버네티스에도 기본적인 cni는 있는데, 크로스 노드 네트워킹, 네트워크 정책 설정과 같은 고급 기능은 지원하지 않는다. 이에 있어서 칼리코, 플란넬과 같은 CNI를 새로 설치해주어야한다.
3. 칼리코 노드 활성화 안됨.
Nat ip가 같아서 생기는 오류이다.
>> 클러스터끼리 다른 nat ip를 할당해준다.
참고
https://itecnote.com/tecnote/kubernetes-calico-node-crashloopbackoff/
1. LoadBalancer type의 서비스를 배포시 pending에서 넘어가지 않는 상태
- 쿠버네티스에서 pending에서 넘어가지 않으면 쿠버네티스에 자체 로드밸런서가 존재하지 않기 때문이라 한다.
- 이에 있어서 metalLB를 설치해 로드밸런서 타입으로 배포를 해야한다.
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.9.3/manifests/namespace.yaml
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.9.3/manifests/metallb.yaml
kubectl create secret generic -n metallb-system memberlist --from-literal=secretkey="$(openssl rand -base64 128)"
metalLB config
apiVersion: v1
kind: ConfigMap
metadata:
namespace: metallb-system
name: config
data:
config: |
address-pools:
- name: default
protocol: layer2
addresses:
- 192.168.56.123-192.168.56.121
Kubectl apply -f metallb-config.yaml
2.
Kubectl 권한이 없음. 해당 파일에 권한을 부여해야함.
Sudo chmod 755 /etc/kubernetes/admin.conf
2. 인증서 설정
Config 설정을 다시 해주어야함.
unset KUBECONFIG
export KUBECONFIG=/etc/kubernetes/admin.conf
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
1.
처음에 kubeadm 을 사용해 쿠버네티스 클러스터를 구성할 때 각종 인증키를 쿠버네티스에 등록하지 않아서 생기는 문제이다.
Sudo kubeadm init –-config configv2.yaml –-upload-certs
–-upload-certs 를 추가하여 각종 인증서와 인증키를 쿠버네티스 configmap에 업로드하자
2. Kube-system의 파드 중 Coredns가 올라오지 않는 상태
각 노드를 인식하지 못해서 생기는 문제이다.
쿠버네티스에도 기본적인 cni는 있는데, 크로스 노드 네트워킹, 네트워크 정책 설정과 같은 고급 기능은 지원하지 않는다. 이에 있어서 칼리코, 플란넬과 같은 CNI를 새로 설치해주어야한다.
3. 칼리코 노드 활성화 안됨.
Nat ip가 같아서 생기는 오류이다.
>> 클러스터끼리 다른 nat ip를 할당해준다.
참고
https://itecnote.com/tecnote/kubernetes-calico-node-crashloopbackoff/
1. LoadBalancer type의 서비스를 배포시 pending에서 넘어가지 않는 상태
- 쿠버네티스에서 pending에서 넘어가지 않으면 쿠버네티스에 자체 로드밸런서가 존재하지 않기 때문이라 한다.
- 이에 있어서 metalLB를 설치해 로드밸런서 타입으로 배포를 해야한다.
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.9.3/manifests/namespace.yaml
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.9.3/manifests/metallb.yaml
kubectl create secret generic -n metallb-system memberlist --from-literal=secretkey="$(openssl rand -base64 128)"
metalLB config
apiVersion: v1
kind: ConfigMap
metadata:
namespace: metallb-system
name: config
data:
config: |
address-pools:
- name: default
protocol: layer2
addresses:
- 192.168.56.123-192.168.56.121
Kubectl apply -f metallb-config.yaml
2.
Kubectl 권한이 없음. 해당 파일에 권한을 부여해야함.
Sudo chmod 755 /etc/kubernetes/admin.conf
2. 인증서 설정
Config 설정을 다시 해주어야함.
unset KUBECONFIG
export KUBECONFIG=/etc/kubernetes/admin.conf
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
1.
처음에 kubeadm 을 사용해 쿠버네티스 클러스터를 구성할 때 각종 인증키를 쿠버네티스에 등록하지 않아서 생기는 문제이다.
Sudo kubeadm init –-config configv2.yaml –-upload-certs
–-upload-certs 를 추가하여 각종 인증서와 인증키를 쿠버네티스 configmap에 업로드하자
2. Kube-system의 파드 중 Coredns가 올라오지 않는 상태
각 노드를 인식하지 못해서 생기는 문제이다.
쿠버네티스에도 기본적인 cni는 있는데, 크로스 노드 네트워킹, 네트워크 정책 설정과 같은 고급 기능은 지원하지 않는다. 이에 있어서 칼리코, 플란넬과 같은 CNI를 새로 설치해주어야한다.
3. 칼리코 노드 활성화 안됨.
Nat ip가 같아서 생기는 오류이다.
>> 클러스터끼리 다른 nat ip를 할당해준다.
참고
https://itecnote.com/tecnote/kubernetes-calico-node-crashloopbackoff/
1. LoadBalancer type의 서비스를 배포시 pending에서 넘어가지 않는 상태
- 쿠버네티스에서 pending에서 넘어가지 않으면 쿠버네티스에 자체 로드밸런서가 존재하지 않기 때문이라 한다.
- 이에 있어서 metalLB를 설치해 로드밸런서 타입으로 배포를 해야한다.
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.9.3/manifests/namespace.yaml
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.9.3/manifests/metallb.yaml
kubectl create secret generic -n metallb-system memberlist --from-literal=secretkey="$(openssl rand -base64 128)"
metalLB config
apiVersion: v1
kind: ConfigMap
metadata:
namespace: metallb-system
name: config
data:
config: |
address-pools:
- name: default
protocol: layer2
addresses:
- 192.168.56.123-192.168.56.121
Kubectl apply -f metallb-config.yaml
2.
Kubectl 권한이 없음. 해당 파일에 권한을 부여해야함.
Sudo chmod 755 /etc/kubernetes/admin.conf
2. 인증서 설정
Config 설정을 다시 해주어야함.
unset KUBECONFIG
export KUBECONFIG=/etc/kubernetes/admin.conf
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
1.
처음에 kubeadm 을 사용해 쿠버네티스 클러스터를 구성할 때 각종 인증키를 쿠버네티스에 등록하지 않아서 생기는 문제이다.
Sudo kubeadm init –-config configv2.yaml –-upload-certs
–-upload-certs 를 추가하여 각종 인증서와 인증키를 쿠버네티스 configmap에 업로드하자
2. Kube-system의 파드 중 Coredns가 올라오지 않는 상태
각 노드를 인식하지 못해서 생기는 문제이다.
쿠버네티스에도 기본적인 cni는 있는데, 크로스 노드 네트워킹, 네트워크 정책 설정과 같은 고급 기능은 지원하지 않는다. 이에 있어서 칼리코, 플란넬과 같은 CNI를 새로 설치해주어야한다.
3. 칼리코 노드 활성화 안됨.
Nat ip가 같아서 생기는 오류이다.
>> 클러스터끼리 다른 nat ip를 할당해준다.
참고
https://itecnote.com/tecnote/kubernetes-calico-node-crashloopbackoff/
1. LoadBalancer type의 서비스를 배포시 pending에서 넘어가지 않는 상태
- 쿠버네티스에서 pending에서 넘어가지 않으면 쿠버네티스에 자체 로드밸런서가 존재하지 않기 때문이라 한다.
- 이에 있어서 metalLB를 설치해 로드밸런서 타입으로 배포를 해야한다.
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.9.3/manifests/namespace.yaml
kubectl apply -f https://raw.githubusercontent.com/metallb/metallb/v0.9.3/manifests/metallb.yaml
kubectl create secret generic -n metallb-system memberlist --from-literal=secretkey="$(openssl rand -base64 128)"
metalLB config
apiVersion: v1
kind: ConfigMap
metadata:
namespace: metallb-system
name: config
data:
config: |
address-pools:
- name: default
protocol: layer2
addresses:
- 192.168.56.123-192.168.56.121
Kubectl apply -f metallb-config.yaml
2.
Kubectl 권한이 없음. 해당 파일에 권한을 부여해야함.
Sudo chmod 755 /etc/kubernetes/admin.conf
2. 인증서 설정
Config 설정을 다시 해주어야함.
unset KUBECONFIG
export KUBECONFIG=/etc/kubernetes/admin.conf
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
1.
처음에 kubeadm 을 사용해 쿠버네티스 클러스터를 구성할 때 각종 인증키를 쿠버네티스에 등록하지 않아서 생기는 문제이다.
Sudo kubeadm init –-config configv2.yaml –-upload-certs
–-upload-certs 를 추가하여 각종 인증서와 인증키를 쿠버네티스 configmap에 업로드하자
2. Kube-system의 파드 중 Coredns가 올라오지 않는 상태
각 노드를 인식하지 못해서 생기는 문제이다.
쿠버네티스에도 기본적인 cni는 있는데, 크로스 노드 네트워킹, 네트워크 정책 설정과 같은 고급 기능은 지원하지 않는다. 이에 있어서 칼리코, 플란넬과 같은 CNI를 새로 설치해주어야한다.
3. 칼리코 노드 활성화 안됨.
Nat ip가 같아서 생기는 오류이다.
>> 클러스터끼리 다른 nat ip를 할당해준다.
참고
https://itecnote.com/tecnote/kubernetes-calico-node-crashloopbackoff/
'쿠버네티스,도커' 카테고리의 다른 글
| RAFT 리더 선출 알고리즘 (0) | 2022.10.11 |
|---|---|
| 쿠버네티스 정리중 (0) | 2022.10.10 |
| 쿠버네티스 kubeadm 설치 과정 정리. (0) | 2022.10.07 |
| calico 동작 (0) | 2022.10.03 |
| 가상화, TYPE1, TYPE2 // 반가상화, 전가상화 (0) | 2022.09.28 |
