K8S 배포 프로세스를 연습 노트는 두 가지 버전이었다 클러스터 : 하나 설명하는 배포 작업을 포함하는 전용 배포 작업입니다. 이 문서는 후자입니다.
이 문서에서는 알리 구름 미러링, 16.04 (64)는 듀얼 코어 CPU 가상 컴퓨터 배포는 Kubernetes 1.17.0 클러스터 처리, 플란넬 v0.11.0에 대한 플러그인 네트워크 비트 모두 우분투에 kubeadm을 사용하는 방법에 대해 설명합니다. 이 문서에서는 몇 가지 구체적인 기준 값을 갖습니다.
첫째, 환경
두 우분투 16.04 64 비트, 2GB 메모리, 듀얼 코어 CPU.
환경 요구 사항 및 설정 :
두 호스트, 마스터에 대한 하나의 노드 하나. 마스터 호스트 이름은 우분투입니다. 노드에 대한 노드 호스트 이름입니다. 호스트 운영 체제의 이름은 서로 다른을 보장합니다.
프로젝트 디렉토리 : $ HOME / K8S.
모든 작업은 루트 권한으로 실행 (참고 : 사용자가 이론적으로 일반 수도, 위해 피할 기관에, 현명 이동하므로).
참고, 기계의 K8S 요구 사항은 듀얼 코어 CPU 이상이어야합니다.
1.17.0의이 문서 배포 K8S 버전. 적시성에 늦게하시기 바랍니다 지불 관심에 12 월 중순 2019 년에 대한 배포 날짜입니다.
다음과 같이 배포 및 버전을 미러링 :
k8s.gcr.io/kube-apiserver:v1.17.0
k8s.gcr.io/kube-controller-manager:v1.17.0
k8s.gcr.io/kube-scheduler:v1.17.0
k8s.gcr.io/kube-proxy:v1.17.0
k8s.gcr.io/pause:3.1
k8s.gcr.io/etcd:3.4.3-0
k8s.gcr.io/coredns:1.6.5
quay.io/coreos/flannel:v0.11.0-amd64
참고 : 주소 registry.aliyuncs.com/google_containers를 사용하여 알리 구름 이미지를 교체 k8s.gcr.io.
둘째, 설치 고정 표시기
apt-get install docker.io
이 문서에서는 고정 표시기 버전 18.09.7를 설치됩니다.
새로운 다음 명령 파일을 실행 /etc/docker/daemon.json :
cat > /etc/docker/daemon.json <<-EOF
{
"registry-mirrors": [
"https://a8qh6yqv.mirror.aliyuncs.com",
"http://hub-mirror.c.163.com"
],
"exec-opts": ["native.cgroupdriver=systemd"]
}
EOF
해석 :
거울 가속기 주소의 레지스트리 거울.
systemd cgroup의 표현을 사용 native.cgroupdriver = systemd 드라이브 (본 실시 K8S), 디폴트는 cgroupfs이다. 그 이유는 수정 K8S에 실패 드라이브 수정 kubeadm.conf입니다.
다시 고정 표시기, cgroup에 참조 :
# systemctl restart docker
# docker info | grep -i cgroup
Cgroup Driver: systemd
수정은 성공을 나타냅니다 Systemd.
셋째, 마스터 배치는 호스트 K8S
배포 서브 마스터 노드와 호스트 노드 K8S. 이 섹션에서는 마스터 호스트입니다.
3.1 닫기 스왑
편집은 / etc / fstab에 파일, 스왑 파티션 밖으로 코멘트는 예를 들어, 라인을 장착 :
# swap was on /dev/sda5 during installation
UUID=aaa38da3-6e60-4e9d-bfc6-7128fd05f1c7 none swapsw 0 0
그런 다음 실행 :
# swapoff -a
국산 원 3.2 K8S 추가
여기에 선택의 알리 구름 :
# cat <<EOF > /etc/apt/sources.list.d/kubernetes.list
deb https://mirrors.aliyun.com/kubernetes/apt/ kubernetes-xenial main
EOF
키를 추가합니다 :
# cat https://packages.cloud.google.com/apt/doc/apt-key.gpg | sudo apt-key add -
실패하면, 다수의 방법을 통해 첫 번째 다운로드 : HTTPS : //packages.cloud.google.com/apt/doc/apt-key.gpg, 프로젝트 디렉토리에. 그런 다음 실행 :
# cat apt-key.gpg | sudo apt-key add -
참고 : (유효 2019 년 12 월 31 일로) 주소 https://www.cststudio.com.cn/dl/apt-key.gpg 다운로드를 사용할 수 있습니다.
3.3 업데이트 소스
# apt-get update
설치 kubeadm, kubectl, kubelet,는 Kubernetes-CNI 다른 도구.
# apt-get install -y kubeadm kubectl kubelet kubernetes-cni
주 1 : kubeadm 설치가 자동으로 kubectl이 kubelet와는 Kubernetes - CNI, 그것은 단지 kubeadm을 지정할 수 있습니다 설치합니다.
주 2 : 버전 1.17.0을 결과로, 여기에서 설치를 사용할 경우는 Kubernetes-CNI 0.7.5로. 파일이 / var에 / 캐시 / 아파트 / 아카이브에 있습니다 다운로드 / 디렉토리.
3.4 필요한 배치 미러 버전을 구하는
# kubeadm config images list
다음과 같이 출력은 다음과 같습니다
W1214 08:46:14.303158 8461 version.go:101] could not fetch a Kubernetes version from the internet: unable to get URL "https://dl.k8s.io/release/stable-1.txt": Get https://dl.k8s.io/release/stable-1.txt: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
W1214 08:46:14.303772 8461 version.go:102] falling back to the local client version: v1.17.0
W1214 08:46:14.304223 8461 validation.go:28] Cannot validate kube-proxy config - no validator is available
W1214 08:46:14.304609 8461 validation.go:28] Cannot validate kubelet config - no validator is available
k8s.gcr.io/kube-apiserver:v1.17.0
k8s.gcr.io/kube-controller-manager:v1.17.0
k8s.gcr.io/kube-scheduler:v1.17.0
k8s.gcr.io/kube-proxy:v1.17.0
k8s.gcr.io/pause:3.1
k8s.gcr.io/etcd:3.4.3-0
k8s.gcr.io/coredns:1.6.5
전면 프롬프트 경고 정보는 무시 될 수 있습니다. 여기에 응답이다 이 릴리스 kubeadm 미러 일치의 버전 으로 인해 발생할 수있는 각 버전 호환성 문제의 다른 구성 요소.
3.5 미러 파일 당기는.
일반적으로, 국가가 직접 k8s.gcr.io 미러 이미지를 다운로드 할 수 없습니다. 두 가지 방법이 있습니다
아래의 초기화 참조 주소를 사용하여 알리 구름 이미지, 주소가 다운로드됩니다 초기화 K8S에서 1.
2, 좋은 이미지를 다운로드합니다. (스크립트가 x 속성을 추가해야합니다) 스크립트 pullk8s.sh 다음을 사용합니다 :
#!/bin/bash
# 下面的镜像应该去除"k8s.gcr.io/"的前缀，版本换成kubeadm config images list命令获取到的版本
images=(
kube-apiserver:v1.17.0
kube-controller-manager:v1.17.0
kube-scheduler:v1.17.0
kube-proxy:v1.17.0
pause:3.1
etcd:3.4.3-0
coredns:1.6.5
)
for imageName in ${images[@]} ; do
docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/$imageName
docker tag registry.cn-hangzhou.aliyuncs.com/google_containers/$imageName k8s.gcr.io/$imageName
docker rmi registry.cn-hangzhou.aliyuncs.com/google_containers/$imageName
done
당기 :
chmod +x pullk8s.sh
bash pullk8s.sh (或 ./pullk8s.sh)
3.6 네트워크
설정 네트워크 구성 :
mkdir -p /etc/cni/net.d
cat >/etc/cni/net.d/10-mynet.conf <<-EOF
{
"cniVersion": "0.3.0",
"name": "mynet",
"type": "bridge",
"bridge": "cni0",
"isGateway": true,
"ipMasq": true,
"ipam": {
"type": "host-local",
"subnet": "10.244.0.0/16",
"routes": [
{"dst": "0.0.0.0/0"}
]
}
}
EOF
cat >/etc/cni/net.d/99-loopback.conf <<-EOF
{
"cniVersion": "0.3.0",
"type": "loopback"
}
EOF
연습이 단계는 할 수 없습니다.
3.7 다운로드 미러 플란넬
docker pull quay.io/coreos/flannel:v0.11.0-amd64
참고 :이 다운로드 할 수없는 경우, 당신은 다른 방법을 사용해야합니다.
미러링 정보를 플란넬 :
# docker images | grep flannel
quay.io/coreos/flannel v0.11.0-amd64 ff281650a721 11 months ago 52.6MB
3.8 초기화
버전 1 :
kubeadm init --pod-network-cidr=10.244.0.0/16 \
--image-repository registry.aliyuncs.com/google_containers
해석 :
-POD 네트워크 세그먼트 CIDR 네트워크 지정은 (본원에서 사용 된 융) 이후의 네트워크를 연결하는데 사용될 것이다.
미러 주소 지정 - 이미지 - 저장소, 기본은 알리 구름이 주소 registry.aliyuncs.com/google_containers 미러 여기에 지정된 k8s.gcr.io이다.
다른 매개 변수의 기본을합니다.
상기 명령에 상응하는 명령을 따른다 :
kubeadm init \
--apiserver-advertise-address=192.168.0.102 \
--image-repository registry.aliyuncs.com/google_containers \
--kubernetes-version v1.17.0 \
--service-cidr=10.1.0.0/16\
--pod-network-cidr=10.244.0.0/16
버전 두 사람은, 이전에 해당 스크립트의 자신의 버전을 당기에있어서,
kubeadm init --pod-network-cidr=10.244.0.0/16
본 명세서에서 사용 된 바와 같이, 버전이 배포 .
다음과 같은 메시지 초기화 프로세스는 다음과 같습니다
W1221 17:44:19.880281 2865 version.go:101] could not fetch a Kubernetes version from the internet: unable to get URL "https://dl.k8s.io/release/stable-1.txt": Get https://dl.k8s.io/release/stable-1.txt: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
W1221 17:44:19.880405 2865 version.go:102] falling back to the local client version: v1.17.0
W1221 17:44:19.880539 2865 validation.go:28] Cannot validate kube-proxy config - no validator is available
W1221 17:44:19.880546 2865 validation.go:28] Cannot validate kubelet config - no validator is available
[init] Using Kubernetes version: v1.17.0
[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'
[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
[certs] Using certificateDir folder "/etc/kubernetes/pki"
[certs] Generating "ca" certificate and key
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [ubuntu kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 192.168.0.102]
[certs] Generating "apiserver-kubelet-client" certificate and key
[certs] Generating "front-proxy-ca" certificate and key
[certs] Generating "front-proxy-client" certificate and key
[certs] Generating "etcd/ca" certificate and key
[certs] Generating "etcd/server" certificate and key
[certs] etcd/server serving cert is signed for DNS names [ubuntu localhost] and IPs [192.168.0.102 127.0.0.1 ::1]
[certs] Generating "etcd/peer" certificate and key
[certs] etcd/peer serving cert is signed for DNS names [ubuntu localhost] and IPs [192.168.0.102 127.0.0.1 ::1]
[certs] Generating "etcd/healthcheck-client" certificate and key
[certs] Generating "apiserver-etcd-client" certificate and key
[certs] Generating "sa" key and public key
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "kubelet.conf" kubeconfig file
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[kubeconfig] Writing "scheduler.conf" kubeconfig file
[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"
W1221 17:50:12.262505 2865 manifests.go:214] the default kube-apiserver authorization-mode is "Node,RBAC"; using "Node,RBAC"
[control-plane] Creating static Pod manifest for "kube-scheduler"
W1221 17:50:12.268198 2865 manifests.go:214] the default kube-apiserver authorization-mode is "Node,RBAC"; using "Node,RBAC"
[etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
[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
[apiclient] All control plane components are healthy after 17.504683 seconds
[upload-config] Storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config-1.17" in namespace kube-system with the configuration for the kubelets in the cluster
[upload-certs] Skipping phase. Please see --upload-certs
[mark-control-plane] Marking the node ubuntu as control-plane by adding the label "node-role.kubernetes.io/master=''"
[mark-control-plane] Marking the node ubuntu as control-plane by adding the taints [node-role.kubernetes.io/master:NoSchedule]
[bootstrap-token] Using token: 1rpp8b.axfud1xrsvx4q8nw
[bootstrap-token] Configuring bootstrap tokens, cluster-info ConfigMap, RBAC Roles
[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
[addons] Applied essential addon: kube-proxy
Your Kubernetes control-plane has initialized successfully!
To start using your cluster, you need to run the following as a regular user:
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
https://kubernetes.io/docs/concepts/cluster-administration/addons/
Then you can join any number of worker nodes by running the following on each as root:
kubeadm join 192.168.0.102:6443 --token 1rpp8b.axfud1xrsvx4q8nw \
--discovery-token-ca-cert-hash sha256:6bf952d45bbdc121fa90583eac33f11f0a3f4b491f29996a56fc289363843e3c
먼저 K8S 버전을 확인했다.
그리고 이러한 인증서로, 구성 파일을 만듭니다.
포드을 다시 만듭니다.
마지막 클러스터 명령 프롬프트를 가입.
K8S 배포의 개념을 깊이 이해하지 않는 것이 좋습니다.
잊어 버린 경우, 예를 들어, --print-조인 명령 참조를 만들 토큰 kubeadm 수 있습니다 :
W1221 21:23:37.632172 5479 validation.go:28] Cannot validate kube-proxy config - no validator is available
W1221 21:23:37.632503 5479 validation.go:28] Cannot validate kubelet config - no validator is available
kubeadm join 192.168.0.102:6443 --token r9ip8i.9rs35l98nj3cquey --discovery-token-ca-cert-hash sha256:6bf952d45bbdc121fa90583eac33f11f0a3f4b491f29996a56fc289363843e3c
메시지가 표시되면, 현재 파일에 따라 인 admin.conf 각각의 사용자 디렉토리를 복사합니다. 이후 파일 인 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
초기화하는 동안 같은 자동으로 다음과 같이 초기화 거울을 존재하지 않는 이미지를 다운로드 :
# docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
registry.aliyuncs.com/google_containers/kube-proxy v1.17.0 7d54289267dc 13 days ago 116MB
registry.aliyuncs.com/google_containers/kube-apiserver v1.17.0 0cae8d5cc64c 13 days ago 171MB
registry.aliyuncs.com/google_containers/kube-controller-manager v1.17.0 5eb3b7486872 13 days ago 161MB
registry.aliyuncs.com/google_containers/kube-scheduler v1.17.0 78c190f736b1 13 days ago 94.4MB
registry.aliyuncs.com/google_containers/coredns 1.6.5 70f311871ae1 6 weeks ago 41.6MB
registry.aliyuncs.com/google_containers/etcd 3.4.3-0 303ce5db0e90 8 weeks ago 288MB
registry.aliyuncs.com/google_containers/pause 3.1 da86e6ba6ca1 2 years ago 742kB
이 때, 포드의 상태는 다음과 같습니다 :
# kubectl get pods -n kube-system
NAME READY STATUS RESTARTS AGE
coredns-9d85f5447-67qtv 0/1 Pending 0 3h26m
coredns-9d85f5447-cg87c 0/1 Pending 0 3h26m
etcd-ubuntu 1/1 Running 0 3h27m
kube-apiserver-ubuntu 1/1 Running 0 3h27m
kube-controller-manager-ubuntu 1/1 Running 0 3h27m
kube-proxy-chqbq 1/1 Running 0 3h26m
kube-scheduler-ubuntu 1/1 Running 0 3h27m
보류 상태 추가 coredns에서 다른 포드 운영하고 있습니다. 야기되는 네트워크 배치 플러그가 없기 때문이다. 플란넬의이보세요.
3.9 배치 플란넬
배포 플란넬에 다음 명령을 실행합니다 :
# kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
해석 :
사용 KUBE-flannel.yml 파일 플란넬웨어 하우스 구축. 자세한 사항은 파일을 참조 할 수있다.
당신이 액세스 할 수없는 경우, 수동으로 현재 디렉토리에 파일을 https://github.com/coreos/flannel/blob/master/Documentation/kube-flannel.yml 다운로드하고 실행할 수있는 kubectl apply -f kube-flannel.yml명령을.
# kubectl apply -f kube-flannel.yml
podsecuritypolicy.policy/psp.flannel.unprivileged created
clusterrole.rbac.authorization.k8s.io/flannel created
clusterrolebinding.rbac.authorization.k8s.io/flannel created
serviceaccount/flannel created
configmap/kube-flannel-cfg created
daemonset.apps/kube-flannel-ds-amd64 created
daemonset.apps/kube-flannel-ds-arm64 created
daemonset.apps/kube-flannel-ds-arm created
daemonset.apps/kube-flannel-ds-ppc64le created
daemonset.apps/kube-flannel-ds-s390x created
참고 : 또한, 속도가 빨라집니다 KUBE-플란넬-aliyun.yml을 사용할 수 있지만 "확장 / v1beta1"기호가, 현재 버전은 (이유는 아래에 도착하지 않음)가 사용할 수 없습니다를 지원하지 않습니다.
더 미러 플란넬 자동으로 다운로드를 배포하지 플란넬이있는 한, 그것은 이전에 빠르게 시작 다운로드되었습니다. 다음과 같이 시작하는 동안, 플란넬 상태 변경 :
kube-flannel-ds-amd64-pjj5k 0/1 Init:0/1 0 3s
kube-flannel-ds-amd64-pjj5k 1/1 Running 0 9s
이 단계는 나중에 cni0 및 flannel.1 네트워크 장비, 목록 정보를 생성한다.
플란넬를 배포 할 때 다음과 같은 상태 변화를 coredns :
coredns-9d85f5447-67qtv 0/1 Pending 0 3h43m
coredns-9d85f5447-67qtv 0/1 ContainerCreating 0 3h43m
coredns-9d85f5447-67qtv 0/1 CrashLoopBackOff 2 3h44m
포드 로그보기 :
# kubectl logs coredns-9d85f5447-67qtv -n kube-system
.:53
[INFO] plugin/reload: Running configuration MD5 = 4e235fcc3696966e76816bcd9034ebc7
CoreDNS-1.6.5
linux/amd64, go1.13.4, c2fd1b2
[FATAL] plugin/loop: Loop (127.0.0.1:40392 -> :53) detected for zone ".", see https://coredns.io/plugins/loop#troubleshooting. Query: "HINFO 1045765417707038110.4695109258766463637."
그 이유는 coredns 도메인 이름 확인 문제입니다. ConfigMap 형의 coredns 수정 :
kubectl edit cm coredns -n kube-system
편집에 VIM 기본 (DD)와 함께 삭제 루프 필드 그 라인. 그런 다음 입력 :wq저장하고 종료 할 수 있습니다.
다음과 같이 coredns ConfigMap 형 읽
apiVersion: v1
data:
Corefile: |
.:53 {
errors
health {
lameduck 5s
}
ready
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
ttl 30
}
prometheus :9153
forward . /etc/resolv.conf
cache 30
loop
reload
loadbalance
}
kind: ConfigMap
metadata:
creationTimestamp: "2019-12-21T09:50:31Z"
name: coredns
namespace: kube-system
resourceVersion: "171"
selfLink: /api/v1/namespaces/kube-system/configmaps/coredns
uid: 62485b55-3de6-4dee-b24a-8440052bdb66
참고 : 수동으로 무효, 127 개 세그먼트의 복구를 다시 시작 이론적으로, 8.8.8.8에 /etc/resolv.conf 파일 수정은 해결할 수 있어야하지만 파일이 수정됩니다. 삭제 루프 필드는 문제를 해결한다.
문제를 삭제 모든 coredns :
# kubectl delete pod coredns-9d85f5447-67qtv coredns-9d85f5447-cg87c -n kube-system
pod "coredns-9d85f5447-67qtv" deleted
pod "coredns-9d85f5447-cg87c" deleted
삭제 후, coredns가 자동으로 다시 시작됩니다. 보기 깍지 :
# kubectl get pod -n kube-system
NAME READY STATUS RESTARTS AGE
coredns-9d85f5447-bhf24 1/1 Running 0 10s
coredns-9d85f5447-smgz9 1/1 Running 0 10s
etcd-ubuntu 1/1 Running 0 3h58m
kube-apiserver-ubuntu 1/1 Running 0 3h58m
kube-controller-manager-ubuntu 1/1 Running 0 3h58m
kube-flannel-ds-amd64-pjj5k 1/1 Running 0 14m
kube-proxy-chqbq 1/1 Running 0 3h57m
kube-scheduler-ubuntu 1/1 Running 0 3h58m
모든 포드 모두를 실행하고있다.
참고 : 또는 ConfigMap 형, 배포 플란넬을 수정할 수 있습니다.
이 시점에서, 마스터 노드가 성공적으로 배포되었습니다 .
보기 플란넬 네트워크 정보 :
# cat /run/flannel/subnet.env
FLANNEL_NETWORK=10.244.0.0/16
FLANNEL_SUBNET=10.244.0.1/24
FLANNEL_MTU=1450
FLANNEL_IPMASQ=true
이 IP 정보를 확인 :
# ifconfig
cni0 Link encap:Ethernet HWaddr 3e:ce:1f:4a:67:d3
inet addr:10.244.0.1 Bcast:0.0.0.0 Mask:255.255.255.0
inet6 addr: fe80::3cce:1fff:fe4a:67d3/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1450 Metric:1
RX packets:269112 errors:0 dropped:0 overruns:0 frame:0
TX packets:303520 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:18543053 (18.5 MB) TX bytes:87215483 (87.2 MB)
docker0 Link encap:Ethernet HWaddr 02:42:e4:10:57:4a
inet addr:172.17.0.1 Bcast:172.17.255.255 Mask:255.255.0.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
ens33 Link encap:Ethernet HWaddr 00:0c:29:f4:c1:06
inet addr:192.168.0.102 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::49d4:fd5c:17ef:d637/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:202896 errors:0 dropped:0 overruns:0 frame:0
TX packets:183666 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:27411397 (27.4 MB) TX bytes:183832306 (183.8 MB)
flannel.1 Link encap:Ethernet HWaddr aa:2a:8b:e7:92:2b
inet addr:10.244.0.0 Bcast:0.0.0.0 Mask:255.255.255.255
UP BROADCAST RUNNING MULTICAST MTU:1450 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:38 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
보기 플란넬 네트워크 구성 :
# cat /etc/cni/net.d/10-flannel.conflist
{
"name": "cbr0",
"cniVersion": "0.3.1",
"plugins": [
{
"type": "flannel",
"delegate": {
"hairpinMode": true,
"isDefaultGateway": true
}
},
{
"type": "portmap",
"capabilities": {
"portMappings": true
}
}
]
}
(의심 여기 CNI 버전 0.3.1은 CNI는 조사 전에 본 버전과 일치하지 않는다.)
네, 노드 노드
배포 서브 마스터 노드와 호스트 노드 K8S. 이 노드는 노드 섹션입니다.
4.1 전치 조건
노드 노드 작업.
도 1은 설치 kubeadm은 위 참조.
2 플란넬 이미지 다운로드는, 상기 참조 (이전 클러스터에 추가 될 때 자동으로 다운로드되는 다운로드되지 않은 경우).
3 노드 /etc/kubernetes/admin.conf 파일을 / etc /는 Kubernetes / 디렉토리에 호스트 노드의 사본. (참고 : 사용은 scp 명령은 마스터 노드 수에서, 거기는 Kubernetes에는 자기가 만든 없음)
4.2 클러스터에 가입
이 시점에서, K8S 서비스가 시작되지 않았습니다. 추가 노드에 다음 명령을 실행합니다 :
kubeadm join 192.168.0.102:6443 --token 1rpp8b.axfud1xrsvx4q8nw \
--discovery-token-ca-cert-hash sha256:6bf952d45bbdc121fa90583eac33f11f0a3f4b491f29996a56fc289363843e3c
다음과 같은 팁 정보는 다음과 같습니다
[preflight] WARNING: JoinControlPane.controlPlane settings will be ignored when control-plane flag is not set.
[preflight] Running pre-flight checks
[preflight] Reading configuration from the cluster...
[preflight] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[kubelet-start] Downloading configuration for the kubelet from the "kubelet-config-1.17" ConfigMap in the kube-system namespace
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Starting the kubelet
[kubelet-start] Waiting for the kubelet to perform the TLS Bootstrap...
This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.
Run 'kubectl get nodes' on the control-plane to see this node join the cluster.
노드 노드는 소스 그래서 클러스터 프로세스가 필요 K8S 거울, 메모를 다운로드합니다 조인, 마스터 호스트는 소스 알리 소스로 지정되어 있습니다.
REPOSITORY TAG IMAGE ID CREATED SIZE
registry.aliyuncs.com/google_containers/kube-proxy v1.17.0 7d54289267dc 2 weeks ago 116MB
registry.aliyuncs.com/google_containers/coredns 1.6.5 70f311871ae1 7 weeks ago 41.6MB
quay.io/coreos/flannel v0.11.0-amd64 ff281650a721 11 months ago 52.6MB
registry.aliyuncs.com/google_containers/pause 3.1 da86e6ba6ca1 2 years ago 742kB
성공적으로 가입 한 후, 노드는 다음과 같은 관련 서비스가 실행되고있다 :
# ps aux | grep kube
root 3269 1.6 4.2 754668 86784 ? Ssl Dec20 18:34 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --cgroup-driver=cgroupfs --network-plugin=cni --pod-infra-container-image=registry.aliyuncs.com/google_containers/pause:3.1
root 3632 0.1 1.1 140104 22412 ? Ssl Dec20 2:14 /usr/local/bin/kube-proxy --config=/var/lib/kube-proxy/config.conf --hostname-override=node
root 4385 0.0 1.6 407356 33704 ? Ssl Dec20 0:51 /opt/bin/flanneld --ip-masq --kube-subnet-mgr
root 121292 0.0 0.0 14228 1032 pts/0 S+ 00:33 0:00 grep --color=auto kube
kubelet, KUBE-프록시, flanneld 등이있다.
고정 표시기 컨테이너는 다음과 같습니다 :
# docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
2fde9bb78fd7 ff281650a721 "/opt/bin/flanneld -…" 7 minutes ago Up 7 minutes k8s_kube-flannel_kube-flannel-ds-amd64-28p6z_kube-system_f40a2875-70eb-468b-827d-fcb59be3416b_1
aa7ca3d5825e registry.aliyuncs.com/google_containers/kube-proxy "/usr/local/bin/kube…" 8 minutes ago Up 8 minutes k8s_kube-proxy_kube-proxy-n6xv5_kube-system_3df8b7ae-e5b8-4256-9857-35bd24f7e025_0
ac61ed8d7295 registry.aliyuncs.com/google_containers/pause:3.1 "/pause" 8 minutes ago Up 8 minutes k8s_POD_kube-flannel-ds-amd64-28p6z_kube-system_f40a2875-70eb-468b-827d-fcb59be3416b_0
423f9e42c082 registry.aliyuncs.com/google_containers/pause:3.1 "/pause" 8 minutes ago Up 8 minutes k8s_POD_kube-proxy-n6xv5_kube-system_3df8b7ae-e5b8-4256-9857-35bd24f7e025_0
보기 플란넬 네트워크 정보 :
# cat /run/flannel/subnet.env
FLANNEL_NETWORK=10.244.0.0/16
FLANNEL_SUBNET=10.244.1.1/24
FLANNEL_MTU=1450
FLANNEL_IPMASQ=true
이 IP 정보를 확인 :
# ifconfig
cni0 Link encap:Ethernet HWaddr 7a:0b:d3:cc:9c:c2
inet addr:10.244.1.1 Bcast:0.0.0.0 Mask:255.255.255.0
inet6 addr: fe80::780b:d3ff:fecc:9cc2/64 Scope:Link
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:3 errors:0 dropped:0 overruns:0 frame:0
TX packets:136 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:84 (84.0 B) TX bytes:15701 (15.7 KB)
docker0 Link encap:Ethernet HWaddr 02:42:2a:72:1c:91
inet addr:172.17.0.1 Bcast:172.17.255.255 Mask:255.255.0.0
UP BROADCAST MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
ens33 Link encap:Ethernet HWaddr 00:0c:29:96:3c:7a
inet addr:192.168.0.140 Bcast:192.168.0.255 Mask:255.255.255.0
inet6 addr: fe80::a5e3:6e8d:8330:34db/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:815745 errors:0 dropped:0 overruns:0 frame:0
TX packets:280001 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:884087449 (884.0 MB) TX bytes:25231812 (25.2 MB)
flannel.1 Link encap:Ethernet HWaddr ae:98:ae:9b:ae:ef
inet addr:10.244.1.0 Bcast:0.0.0.0 Mask:255.255.255.255
UP BROADCAST RUNNING MULTICAST MTU:1450 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:60 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
V. 검증
마스터 노드에서 수행한다 :
# kubectl get nodes
NAME STATUS ROLES AGE VERSION
node Ready <none> 17m v1.17.0
ubuntu Ready master 5h11m v1.17.0
우리는 준비 상태에 대한했습니다 두 머신을 볼 수 있습니다. 노드 기계는 더 십초에 대한보다 소모는 NotReady 준비로 간다.
비지 박스 간단한 테스트 포드를 사용하여 미러링. 마스터 노드에서 수행한다 :
# kubectl run -i --tty busybox --image=latelee/busybox --restart=Never -- sh
잠시 잠깐, 당신은 비지 박스의 명령 줄을 입력 할 수 있습니다 :
If you don't see a command prompt, try pressing enter.
/ #
/ #
/ # uname -a
Linux busybox 4.4.0-21-generic #37-Ubuntu SMP Mon Apr 18 18:33:37 UTC 2016 x86_64 GNU/Linux
명령 줄에서 다른 하나는, 포드 작동 상태를 참조하십시오
# kubectl get pod -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
busybox 1/1 Running 0 74s 10.244.1.4 node <none> <none>
실행 포드는 노드에서 실행중인 상태로 볼 수있다.
노드에서 노드를보기 :
# docker ps | grep busybox
ba5d1a480294 latelee/busybox "sh" 2 minutes ago Up 2 minutes k8s_busybox_busybox_default_20d757f7-8ea7-4e51-93fc-514029065a59_0
8c643171ac09 registry.aliyuncs.com/google_containers/pause:3.1 "/pause" 2 minutes ago Up 2 minutes k8s_POD_busybox_default_20d757f7-8ea7-4e51-93fc-514029065a59_0
마스터 노드 종료 비지 박스에있는이 시점에서, 포드는 아직 거기가 아니라 READY 상태, 노드 호스트 나 비지 박스 컨테이너 작업.
검증은 성공적인 배포를 K8S .
다른 여섯
6.1 재설정 K8S
root@ubuntu:~/k8s# kubeadm reset
[reset] Reading configuration from the cluster...
[reset] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[reset] WARNING: Changes made to this host by 'kubeadm init' or 'kubeadm join' will be reverted.
[reset] Are you sure you want to proceed? [y/N]: y // !!! 输入y
[preflight] Running pre-flight checks
[reset] Removing info for node "ubuntu" from the ConfigMap "kubeadm-config" in the "kube-system" Namespace
W1215 11:50:28.154924 6848 removeetcdmember.go:61] [reset] failed to remove etcd member: error syncing endpoints with etc: etcdclient: no available endpoints
.Please manually remove this etcd member using etcdctl
[reset] Stopping the kubelet service
[reset] Unmounting mounted directories in "/var/lib/kubelet"
[reset] Deleting contents of config directories: [/etc/kubernetes/manifests /etc/kubernetes/pki]
[reset] Deleting files: [/etc/kubernetes/admin.conf /etc/kubernetes/kubelet.conf /etc/kubernetes/bootstrap-kubelet.conf /etc/kubernetes/controller-manager.conf /etc/kubernetes/scheduler.conf]
[reset] Deleting contents of stateful directories: [/var/lib/etcd /var/lib/kubelet /var/lib/dockershim /var/run/kubernetes /var/lib/cni]
The reset process does not clean CNI configuration. To do so, you must remove /etc/cni/net.d
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 by using the "iptables" command.
If your cluster was setup to utilize IPVS, run ipvsadm --clear (or similar)
to reset your system's IPVS tables.
The reset process does not clean your kubeconfig files and you must remove them manually.
Please, check the contents of the $HOME/.kube/config file.
제거 디렉토리에 다음 명령을 실행하여 네트워크 장비를 삭제 :
rm -rf $HOME/.kube/config
rm -rf /var/lib/cni/
rm -rf /var/lib/kubelet/*
rm -rf /etc/kubernetes/
rm -rf /etc/cni/
ifconfig cni0 down
ifconfig flannel.1 down
ip link delete cni0
ip link delete flannel.1
6.2 노드 시스템 종료
: 마스터에 수행
한 출구 노드 :
# kubectl drain node
node/node cordoned
evicting pod "busybox" // 注：因有 pod 运行，故出现此信息
pod/busybox evicted
node/node evicted
이 프롬프트에서 :
# kubectl get nodes
NAME STATUS ROLES AGE VERSION
node Ready,SchedulingDisabled <none> 18h v1.17.0
ubuntu Ready master 23h v1.17.0
해석 :
노드가되고있다 (이것은 원래의 상태 때문입니다)를 상태를 비는 스케줄 만, 여전히 준비 상태를 유지합니다. 그것은로 이해 될 수있다 "노드의 이용을 금지합니다."
2, 노드를 삭제합니다 :
# kubectl delete node node
node "node" deleted
두 번째 노드의 노드 이름.
더 이상 노드 노드를 볼 수 있습니다.
이 때, 플란넬 노드 노드 KUBE-프록시가 실행되고 있지 않습니다 :
# ps aux | grep kube
root 3269 1.6 4.3 754668 88712 ? Ssl Dec20 18:54 /usr/bin/kubelet --bootstrap-kubeconfig=/etc/kubernetes/bootstrap-kubelet.conf --kubeconfig=/etc/kubernetes/kubelet.conf --config=/var/lib/kubelet/config.yaml --cgroup-driver=cgroupfs --network-plugin=cni --pod-infra-container-image=registry.aliyuncs.com/google_containers/pause:3.1
root 124216 0.0 0.0 14228 964 pts/0 R+ 00:49 0:00 grep --color=auto kube
노드에서 실행 :
# kubeadm reset // 输入 y 确认
(: 마스터는 비슷하지만 다른이 주) 네트워크 장비를 삭제, 제거 디렉토리에 다음 명령을 실행합니다 :
ifconfig cni0 down
ip link delete cni0
ifconfig flannel.1 down
ip link delete flannel.1
rm /var/lib/cni/ -rf
rm /etc/kubernetes/ -rf
rm /var/lib/kubelet/ -rf
참고 : 현재 우아한 출구 노드 노드 방법은 아직 발견되지 않은 저자.
말
나는 전에 여러 시도가 실패한 후, 종료 삭제 노드 구성하고 재 참여 다음 클러스터에 참여, 연습에서 발견합니다. 새 가상 컴퓨터 리눅스, 변경 고정 표시기 후, 다음 클러스터에 가입 할 마지막을 다시 다운로드 kubeadm, 플란넬, 추가 인 admin.conf 호스트 이름을 변경하고, 성공이 될 수 있습니다. (참고 : 원인에 대한 이해를 깊게하는 후속의 추가 검토를 보류 알 수있다).
더 K8S 작업은 작업의 중복을 줄이기 위해 점진적으로 단계를 저장하는 가상 컴퓨터 스냅 샷 기능을 사용하여 수행 할 수 있습니다.
자원
본 논문에서는 실제 상황에 따라 배포의 다음 문서를 참조 및 조정 :
- https://juejin.im/post/5b8a4536e51d4538c545645c
- https://zhuanlan.zhihu.com/p/46341911
- https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/ (공식)
