Kubernetes零基礎搭建集群和核心功能

K8s的介紹和架構

一.什么是kubernetes

Kubernetes(k8s)是Google開源的容器集群管理系統(谷歌內部:Borg),

目前已經成為容器編排一個標準。在Docker技術的基礎上，為容器化的應用提

供部署運行、資源調度、服務發(fā)現和動態(tài)伸縮、高可用等一系列完整功能，提

高了大規(guī)模容器集群管理的便捷性。

Kubernetes優(yōu)勢:

，容器編排

-輕量級

-開源

-彈性伸縮

-負載均衡

二、Kubernetes架構和組件

?用戶通過kubectl提交需要運行的docker

container(pod)

?apiserver把請求存儲在etcd里面

?scheduler掃描,分配機器

?kubelet:找到自己需要跑的container,

在本機上運行

?用戶提交RC描述,replication

controller監(jiān)視集群中的容器并保持數量

?用戶提交service描述文件，由kube

proxy負責具體的工作流量轉發(fā)

2.1核心組件

2.1.1KubernetesMaster控制組件，調度管理整個系統(集群)，包含如下

組件：

a、KubernetesAPIServer

作為Kubernetes系統的入口，其封裝了核心對象的增刪改查操作，以

RESTfulAPI接口方式提供給外部客戶和內部組件調用。它是系統管理指令的

統一入口，任何對資源進行增刪改查的操作都要交給APIServer處理后再提交

給etcdokubectl是直接和APIServer交互的。

a,提供了資源對象的唯一操作入口，其他所有組件都必須通過它提供的API來

操作資源數據，只有APIServer與存儲通信，其他模塊通過APIServer訪問

集群狀態(tài)。實現集群故障檢測和恢復的自動化工作，負責執(zhí)行各種控制器，主

要有：

第一，是為了保證集群狀態(tài)訪問的安全。

第二，是為了隔離集群狀態(tài)訪問的方式和后端存儲實現的方式：APIServer

是狀態(tài)訪問的方式，不會因為后端存儲技術etcd的改變而改變。

b,作為kubernetes系統的入口，封裝了核心對象的增刪改查操作，以

RESTFul接口方式提供給外部客戶和內部組件調用。對相關的資源數據“全量

查詢”+“變化監(jiān)聽”，實時完成相關的業(yè)務功能

b、KubernetesScheduler

為新建立的Pod進行節(jié)點（node）選擇（即分配機器）,**負責集群的資源調度

**。組件抽離，可以方便替換成其他調度器。

a,Scheduler收集和分析當前Kubernetes集群中所有Minion/Node節(jié)點的資源

（內存、CPU）負載情況，然后依此分發(fā)新建的Pod到Kube門）etes集群中可用的

節(jié)點。

b,實時監(jiān)測Kubernetes集群中未分發(fā)和已分發(fā)的所有運行的Pod。

c,Scheduler也監(jiān)測Minion/Node節(jié)點信息，由于會頻繁查找Minion/Node節(jié)

點，Scheduler會緩存一份最新的信息在本地。

d,Scheduler在分發(fā)Pod到指定的Minion/Node節(jié)點后，會把Pod相關的信息

Binding寫回APIServer。

c、KubernetesController

負責執(zhí)行各種控制器，目前已經提供了很多控制器來保證Kubernetes的正常運

行。

-ReplicationController

管理維護ReplicationController,關聯ReplicationController

和Pod,保證ReplicationController定義的副本數量與實際運行Pod數量一

致。

-NodeController

管理維護Node,定期檢查Node的健康狀態(tài)，標識出（失效|未失效）的

Node節(jié)點。

-NamespaceController

管理維護Namespace,定期清理無效的Namespace,包括Namesapce下

的API對象，比如Pod、Service等。

-ServiceController

管理維護Service,提供負載以及服務代理。

-EndPointsController

管理維護Endpoints,關聯Service和Pod,創(chuàng)建Endpoints為

Service的后端，當Pod發(fā)生變化時，實時更新Endpoints。

-ServiceAccountController

管理維護ServiceAccount,為每個Namespace創(chuàng)建默認的Service

Account,同時為ServiceAccount倉Ll建ServiceAccountSecreto

-PersistentVolumeController

管理維護PersistentVolume和PersistentVolumeClaim,為新的

PersistentVolumeClaim分配PersistentVolume進行綁定，為釋放的

PersistentVolume執(zhí)行清理回收。

-DaemonSetController

管理維護DaemonSet,負責創(chuàng)建DaemonPod,保證指定的Node上正

常的運行DaemonPod。

-DeploymentController

管理維護Deployment,關聯Deployment和Replication

Controller,保證運行指定數量的Pod。當Deployment更新時，控制實現

ReplicationController和Pod的更新。

-JobController

管理維護Job,為Jod創(chuàng)建一次性任務Pod,保證完成Job指定完成的

任務數目

-PodAutoscalerController

實現Pod的自動伸縮，定時獲取監(jiān)控數據，進行策略匹配，當滿足條

件時執(zhí)行Pod的伸縮動作。

2.1.2KubernetesNode運行節(jié)點，運行管理業(yè)務容器，包含如下組件：

a、Kubelet

負責管控容器，Kubelet會從KubernetesAPIServer接收Pod的創(chuàng)建請

求，啟動和停止容器，監(jiān)控容器運行狀態(tài)并匯報給KubernetesAPIServero

b、KubernetesProxy

負責為Pod創(chuàng)建代理服務，KubernetesProxy會從KubernetesAPIServer

獲取所有的Service信息，并根據Service的信息創(chuàng)建代理服務，實現

Service到Pod的請求路由和轉發(fā)，從而實現Kubernetes層級的虛擬轉發(fā)網

絡。該模塊實現了Kubernetes中的服務發(fā)現和反向代理功能。

反向代理方面:kube-proxy支持TCP和UDP連接轉發(fā)，默認基于RoundRobin

算法**將客戶端流量轉發(fā)到與service對應的一組后端pod。

**服務發(fā)現方面：kube-proxy使用etcd的watch機制，監(jiān)控集群中service

和endpoint對象數據的動態(tài)變化，并且維護一個service到endpoint的映射

關系，從而保證了后端pod的IP變化不會對訪問者造成影響。另外kube-

proxy還支持sessionaffinityo

c、Docker

Node上需要運行容器服務。

2.1.3master和node之外的組件：

a、etcd

一個高可用的K/V鍵值對存儲和服務發(fā)現系統，etcd的功能是給flannel提供

數據存儲，可以單機部署或者集群部署。

b、flannel

這里并不一定非要是flannel,也可以是其他。所有node上都是以flannel為

主流來進行部署。**所有node節(jié)點上的docker啟動的時候需要flannel分發(fā)

IP地址，而flannel就會去請求etcd中的配置，各個node分配不同的IP網

段，類似于咱路由器DHCP的功能，這樣就有效的避免了IP地址的沖突，同時

flannel對docker容器的數據包進行轉發(fā)到另一個node節(jié)點上，flannel服

務這樣就實現了整個K8S集群中docker容器網絡互通問題。**

kubernetes基本概念

Cluster

Cluster是計算、存儲和網絡資源的集合，Kubernetes利用這些資源運行各種

基于容器的應用。

Master

Master是Cluster的大腦，它的主要職責是調度，即決定將應用放在哪里運

行。Master運行在Linux操作系統，可以是物理機或者虛擬機。為了實現高可

用，可以運行多個Master。

Node

Node的指責是運行容器應用。Node由Master管理，Node負責監(jiān)控并匯報容器

的狀態(tài)，并根據Master的要求管理容器的生命周期。Node運行在Linux操作

系統，可以是物理機或者是虛擬機。

Pod

Pod是Kubernetes的最小工作單元。每個Pod包含一個或多個容器。Pod中的

容器會作為一個整體被Master調度到一個Node上運行。Kubernetes引入Pod

主要基于下面兩個目的：

①可管理性。有些容器天生就是需要緊密聯系，一起工作。Pod提供了比容器

更高層次的抽象，將它們封裝到一個部署單元中。Kubernetes以Pod為最小單

位進行調度、擴展、共享資源、管理生命周期。

②通信和資源共享。Pod中的所有容器使用同一個網絡namespaces,即相同的

IP地址和Port空間。它們可以直接用localhost通信。同樣的，這些容器可

以共享存儲，當Kubernetes掛載volume到Pod,本質上是將volume掛載到

Pod中的每一個容器。

Pod有兩種使用方式：

?運行單一容器。

one-container-per-Pod是Kubernetes最常見的模型，這種情況下，只是將單個容

器簡單封裝成Pod。即便是只有一個容器，Kubernetes管理的也是Pod而不是直

接管理容器。

?運行多個容器。

但問題在于：哪些容器應該放在一個Pod中？答案是：這些容器聯系必須非常緊

密，而且需要直接共享資源。舉個例子。Pod包含兩個容器，一個是FilePuller,

一個是WebServer。

FilePuller會定期從外部的ContentManager中拉取最新的文件，將其存放在共享

的volume中。WebServer從volume讀取文件，響應Consumer的請求。

這兩個容器是緊密協作的，它們一起作為Consumer提供最新的數據；同時它們也

通過volume共享數據。所以放到一個Pod是合適的。

再看一個反例：是否需要將Tomcat和MySQL放到一個Pod中？Tomcat從

MySQL讀取數據，它們之間需要協作，但還不至于需要放到一個Pod中一起部

署，一起啟動，一起停止。同時它們是之間通過JDBC交換數據，并不是直接共享

存儲，所以放到各自的Pod中更合適。

Controller

Kubernetes通常不會直接創(chuàng)建Pod,而是通過Controller來管理Pod的。

Controller中定義了Pod的部署特性，比如有幾個副本，在什么樣的Node上

運行等。為了滿足不同的業(yè)務場景，Kubernetes提供了多種Controller,包括

Deployment>ReplicaSet、DaemonSet>StatefuleSet、Job等。Deployment是

最常用的Controller,比如前面就是通過Deployment來部署應用的。

Deployment可以管理Pod的多個副本，并確保Pod按照期望的狀態(tài)運行。

ReplicaSet實現了Pod的多副本管理。使用Deployment時會自動創(chuàng)建

ReplicaSet,也就是說Deployment是通過ReplicaSet來管理Pod的多個副

本，我們通常不需要直接使用ReplicaSet。DaemonSet用于每個Node最多只運

行一個Pod副本的場景。正如其名稱所揭示的，DaemonSet通常用于運行

daemonoStatefuleSet能夠保證Pod的每個副本在整個生命周期中名稱是不變

的。而其他Controller不提供這個功能，當某個Pod發(fā)生故障需要刪除并重新

啟動時，Pod的名稱會發(fā)生變化。同時StatefuleSet會保證副本按照固定的順

序啟動、更新或者刪除。Job用于運行結束就刪除的應用。而其他Controller

中的Pod通常是長期持續(xù)運行。

復制控制器(ReplicationController,RC)

RC是K8s集群中最早的保證Pod高可用的API對象。通過監(jiān)控運行中的Pod來

保證集群中運行指定數目的Pod副本。指定的數目可以是多個也可以是1個；

少于指定數目，RC就會啟動運行新的Pod副本；多于指定數目，RC就會殺死多

余的Pod副本。即使在指定數目為1的情況下，通過RC運行Pod也比直接運行

Pod更明智，因為RC也可以發(fā)揮它高可用的能力，保證永遠有1個Pod在運

行。RC是K8s較早期的技術概念，只適用于長期伺服型的業(yè)務類型，比如控制

小機器人提供高可用的Web服務。

副本集(ReplicaSet,RS)

RS是新一代RC,提供同樣的高可用能力，區(qū)別主要在于RS后來居上，能支持

更多種類的匹配模式。副本集對象一般不單獨使用，而是作為Deployment的理

想狀態(tài)參數使用。

部署(Deployment)

部署表示用戶對K8s集群的一次更新操作。部署是一個比RS應用模式更廣的

API對象，可以是創(chuàng)建一個新的服務，更新一個新的服務，也可以是滾動升級

一個服務。滾動升級一個服務，實際是創(chuàng)建一個新的RS,然后逐漸將新RS中

副本數增加到理想狀態(tài)，將舊RS中的副本數減小到0的復合操作；這樣一個復

合操作用一個RS是不太好描述的，所以用一個更通用的Deployment來描述。

以K8s的發(fā)展方向，未來對所有長期伺服型的的業(yè)務的管理，都會通過

Deployment來管理。

月艮務(Service)

Deployment可以部署多個副本，每個Pod都有自己的IP,外界如何訪問這些副

本呢？通過Pod的IP嗎？要知道Pod很可能會被頻繁地銷毀和重啟，它們的

IP會發(fā)生變化，用IP來訪問不太現實。答案是Service。Kubernetes

Service定義了外界訪問一組特定Pod的方式。Service有自己的IP和端口，

Service為Pod提供了負載均衡。Kubernetes運行容器(Pod)與訪問容器

(Pod)這兩項任務分別由Controller和Service執(zhí)行。RC、RS和Deployment

只是保證了支撐服務的微服務Pod的數量，但是沒有解決如何訪問這些服務的

問題。一個Pod只是一個運行服務的實例，隨時可能在一個節(jié)點上停止，在另

一個節(jié)點以一個新的IP啟動一個新的Pod,因此不能以確定的IP和端口號提

供服務。要穩(wěn)定地提供服務需要服務發(fā)現和負載均衡能力。服務發(fā)現完成的工

作，是針對客戶端訪問的服務，找到對應的的后端服務實例。在K8s集群中，

客戶端需要訪問的服務就是Service對象。每個Service會對應一個集群內部

有效的虛擬IP,集群內部通過虛擬IP訪問一個服務。在K8s集群中微服務的

負載均衡是由Kube-proxy實現的。Kube-proxy是K8s集群內部的負載均衡

器。它是一個分布式代理服務器，在K8s的每個節(jié)點上都有一個；這一設計體

現了它的伸縮性優(yōu)勢，需要訪問服務的節(jié)點越多，提供負載均衡能力的Kube-

proxy就越多，高可用節(jié)點也隨之增多。與之相比，我們平時在服務器端做個

反向代理做負載均衡，還要進一步解決反向代理的負載均衡和高可用問題。

Namespace

如果有多個用戶或項目組使用同一個KubernetesCluster,如何將他們創(chuàng)建的

Controller＞Pod等資源分開呢？

答案就是Namespaceo

Namespace可以將一個物理的Cluster邏輯上劃分成多個虛擬Cluster,每個

Cluster就是一個Namespaceo不同Namespace里的資源是完全隔離的。

Kubernetes默認創(chuàng)建了兩個Namespace。

?default-創(chuàng)建資源時如果不指定，將被放到這個Namespace中。

?kube-system-Kubernetes自己創(chuàng)建的系統資源將放到這個Namespace中

K8s集群安裝

一、環(huán)境準備

1.1機器環(huán)境

非常重要必須看咯

1、節(jié)點CPU核數必須是：＞=2核/內存要求必須是：＞=2G,否則k8s無法

啟動

2、DNS網絡：最好設置為本地網絡連通的DNS,否則網絡不通，無法下載一些

鏡像

3、兼容問題

docker19kubernetesl.19.x

docker20kubernetes1.20.x

在k8sl.21.1之后k8s的默認容器不是Docker是Containerd

注意：使用docker版本v20.10.8、kubernetesvl.20.5>Go版本vl.13.15

節(jié)點hostname作用IP

kmasterkmaster0

knodelkworkl1

knode2kwork22

1.2設置主機別名

[root@localhosthostnamectlset-hostnamekmaster-static

[root@localhosthostnamectlset-hostnamekworkerl-static

[root@localhosthostnamectlset-hostnamekworker2--static

1.3服務器靜態(tài)IP配置

[root@localhostvi/etc/sysconfig/network-scripts/ifcfg-enp0s3

BOOTPROTO="static"#dhcp改為static

0NB00T="yes"#開機啟用本配置

IPADDR=192.168.3.10#靜態(tài)IP192.168.8.11/192.168.8.12

GATEWAY=192.168.3.1#默認網關

NETMASK=255.255.255.0#子網掩碼

DNS1=114.114.114.114#DNS配置

DNS2=8.8.8.8#DNS配置【必須配置，否則SDK鏡像下載很慢】

##重啟所有服務器

[root@localhostreboot

1.4查看主機名

##看看別名是否生效

hostname

1.5配置IPhost映射關系

##編輯/etc/hosts文件，配置映射關系

vi/etc/hosts

192.168.3.10kmaster

192.168.3.11kworker1

192.168.3.12kworker2

1.6安裝依賴環(huán)境

注意：每一臺機器都需要安裝此依賴環(huán)境

yuminstall-yconntrackntpdatentpipvsadmipsetjqiptablescurl

sysstatlibseccompwgetvimnet-toolsgitiprouteIrzszbash-

completiontreebridge-utilsunzipbind-utilsgcc

1.7防火墻配置

安裝iptables,啟動iptables,設置開機自啟，清空iptables規(guī)則，保存當

前規(guī)則到默認規(guī)則

#關閉防火墻(生產環(huán)境建議使用放行端口)

systemctlstopfirewalld&&systemctldisablefirewalld

#置空iptables

yum-yinstalliptables-services&&systemctlstartiptables&&

systemctlenableiptables&&iptables-F&&serviceiptablessave

1.8關閉selinux［必須操作］

因為在K8S集群安裝的時候需要執(zhí)行腳本，如果Selinux沒有關閉它會阻止執(zhí)

行。

#關閉swap分區(qū)【虛擬內存】并且永久關閉虛擬內存

swapoff-a&&sed-i7swap/s/\(.*\)$/#\l/g'/etc/fstab

#關閉selinux

setenforce0&&sed-iJs/^SELINUX=.*/SELINUX=disabledZ，

/etc/seiinux/config

二、系統設置調整

2.1調整內核參數

cat>kubernetes.conf<<EOF

net.bridge.bridge-nf-call-iptables=l

net.bridge.bridge-nf-call-ip6tables=l

net.ipv4.ip_forward=l

net.ipv4.tcp_tw_recycle=O

vm.swappiness=O

vm.overcommit_memory=1

vm.panic_on_oom=0

fs.inotify.max_user_instances=8192

fs.inotify.max_user_watches=1048576

fs.file-max=52706963

fs.nr_open=52706963

net.ipv6.conf.all.disable_ipv6=l

net.netfilter.nf_conntrack_max=2310720

EOF

#將優(yōu)化內核文件拷貝到/etc/sysctl.d/文件夾下，這樣優(yōu)化文件開機的時候能

夠被調用

cpkubernetes.conf/etc/sysctl.d/kubernetes.conf

#手動刷新，讓優(yōu)化文件立即生效

sysctl-p/etc/sysctl.d/kubernetes.conf

2.2調整系統臨時區(qū)

#設置系統時區(qū)為中國/上海

timedatectlset-timezone〃Asia/Shanghai〃

#將當前的UTC時間寫入硬件時鐘

timedatectlset-local-rtc0

#重啟依賴于系統時間的服務

systemctlrestartrsyslog

systemctlrestartcrond

2.3關閉系統不需要的服務

systemctlstoppostfix&&systemctldisablepostfix

2.4設置日志保存方式

2.4.1創(chuàng)建保存日志的目錄

mkdir/var/1og/journal

2.4.2創(chuàng)建配置文件存放目錄

mkdir/etc/systemd/journald.conf,d

2.4.3創(chuàng)建配置文件

cat>/etc/systemd/journald.conf,d/99-prophet.conf?E0F

[Journal]

Storage=persistent

Compress=yes

SyncIntervalSec=5m

RateLimitInterval=30s

RateLimitBurst=1000

SystemMaxUse=1OG

SystemMaxFileSize=200M

MaxRetentionSec=2week

ForwardToSyslog=no

EOF

2.4.4重啟systemdjournald的配置

systemctlrestartsystemd-journald

2.4.5打開文件數調整（可忽略，不執(zhí)行）

echo〃*softnofile65536〃?/etc/security/limits.conf

echo〃*hardnofile65536〃?/etc/security/limits.conf

2.4.6kube-proxy開啟ipvs前置條件

modprobebr_netfliter

cat>/etc/sysconfig/modules/ipvs.modules<<EOF

#!/bin/bash

modprobe-ip_vs

modprobe-ip_vs_rr

modprobe一一ip_vs_wrr

modprobe-ip_vs_sh

modprobe一一nf_conntrack_ipv4

EOF

#使用Ismod命令查看這些文件是否被引導

chmod755/etc/sysconfig/modules/ipvs.modules&&bash

/etc/sysconfig/modules/ipvs.modules&&Ismod|grep-eip_vs-e

nf_conntrack_ipv4

=二====二======執(zhí)行結果================

ip_vs_sh163840

ip_vs_wrr163840

ip_vs_rr163840

ip_vs1474566ip_vs_rr,ip_vs_sh,ip_vs_wrr

nf_conntrack_ipv4204800

nf_defrag_ipv4163841nf_conntrack_ipv4

nf_conntrack1146882ip_vs,nf_conntrack_ipv4

libcrc32c163842xfs,ip_vs

三、Docker部署

3.1安裝docker

#安裝依賴

yuminstall-yyum-utilsdevice-mapper-persistent-datalvm2

#緊接著配置一個穩(wěn)定的倉庫、倉庫配置會保存到/etc/yum.repos,d/docker-

ce.repo文件中

yum-config-manager-add-repo

https://download.docker,com/1inux/centos/docker-ce.repo

#更新Yum安裝的相關Docker軟件包&安裝DockerCE(這里安裝Docker最新版

本)

yumupdate-y&&yuminstalldocker-ce

3.2設置dockerdaemon文件

#創(chuàng)建/etc/docker目錄

mkdir/etc/docker

#更新daemon,json文件

cat>/etc/docker/daemon,json<<EOF

(

“registry-mirrors”:[

“https://ebkn7ykm.mirror,aliyuncs.com”,

z，https://docker,mirrors,ustc.edu.cn〃,

/zhttp://f1361db2.m.daocloud.io〃,

，zhttps://registry,docker-cn.com”

1,

〃exec-opts〃：["native.cgroupdriver=systemdz/1,

log-driver:json-file,

〃log-opts〃：{

max-size:100m

},

“storage-driver":"overlay2”

)

EOF

#注意：一定注意編碼問題，出現錯誤-查看命令：journalctl-amudocker

即可發(fā)現錯誤

#創(chuàng)建，存儲docker配置文件

#mkdir-p/etc/systemd/system/docker.service,d

3.3重啟docker服務

systemctldaemon-reload&&systemctlrestartdocker&&systemctl

enabledocker

四、kubeadm安裝K8s

4.1yum倉庫鏡像

國內鏡像配置(國內建議配置)

cat<<EOF>/etc/yum.repos,d/kubernetes.repo

[kubernetes]

name=Kubernetes

baseurl=http://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-

el7-x86_64

enabled=l

gpgcheck=O

repo_gpgcheck=0

gpgkey=http://mirrors,aliyun.com/kubernetes/yum/doc/yum-key.gpg

http://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-

key.gpg

EOF

官網鏡像配置

cat<<EOF>/etc/yum.repos,d/kubernetes.repo

[kubernetes]

name=Kubernetes

baseurl=https://packages,cloud,google.com/yum/repos/kubernetes-el7-

x86_64

enabled=l

gpgcheck=l

repo_gpgcheck=l

gpgkey=https://packages,cloud,google,com/yum/doc/yum-key.gpg

https://packages,cloud.google,com/yum/doc/rpm-package-key.gpg

EOF

4.2安裝kubeadm、kubelet>kubectl(1.20.5)

#指定版本

yuminstall-ykubelet-l.20.5kubeadm-1.20.5kubectl-1.20.5一一

disableexcludes=kubernetes

systemctlenablekubelet&&systemctlstartkubelet

五、準備k8s鏡像

5.1修改配置文件

[root@master']$kubeadmconfigprintinit-defaults>kubeadm-

init.yaml

該文件有兩處需要修改：

?將advertiseAddress:1.2.3.4修改為本機地址，比如使用91作為

master,就修改advertiseAddress:192.168.3.191

?將imageRepository:k8s.ger.io修改為imageRepository:

registry,cn-hangzhou.aliyuncs.com/google_containers

修改完畢后文件如下：

apiVersion:kubeadm.k8s.io/vlbeta2

bootstrapTokens:

-groups:

-system:bootstrappers:kubeadm:default-node-token

token:abedef.0123456789abcdef

ttl:24h0m0s

usages:

-signing

-authentication

kind:InitConfiguration

localAPIEndpoint:

advertiseAddress:192.168.3.191#本機IP

bindPort:6443

nodeRegistration:

criSocket:/var/run/dockershim,sock

name:k8s-master

taints:

-effect:NoSchedule

key:node-role,kubernetes.io/master

apiServer:

timeoutForControlPlane:4m0s

apiVersion:kubeadm.k8s.io/vlbeta2

certificatesDir:/etc/kubernetes/pki

clusterName:kubernetes

controllerManager:{}

dns:

type:CoreDNS

etcd:

local:

dataDir:/var/lib/etcd

imageRepository:registry,cn-hangzhou.aliyuncs.com/google_containers

#鏡像倉庫

kind:ClusterConfiguration

kubernetesVersion:vl.20.1

networking:

dnsDomain:cluster.local

serviceSubnet:10.96.0.0/12

podSubnet:10.244.0.0/16#新增Pod子網絡

scheduler:{}

5.2根據配置文件拉取鏡像

[root@kmaster~]$kubeadmconfigimagespull--configkubeadm-

init.yaml

六、K8s的Master部署

6.1執(zhí)行初始化

[root@master~]$kubeadminit--configkubeadm-init.yaml

6.2驗證是否成功

##如果在執(zhí)行完成后出現下面的語句代表成功并記錄下加入worker節(jié)點的

命令

kubeadmjoin192.168.3.10:6443-tokenabcdef.0123456789abcdef\

-discovery-token-ca-cert-hash

sha256:13aff92657d0f3451ac68e3200ebc3clc6ea6980blde700ba257adl538e0ce

3

6.3查看Master節(jié)點網絡狀態(tài)

##配置kubectl執(zhí)行命令環(huán)境

mkdir-p$H0ME/.kube

cp-i/etc/kubernetes/admin.conf$H0ME/.kube/config

chown$(id-u):$(id-g)$H0ME/.kube/config

##執(zhí)行kubectl命令查看機器節(jié)點

kubectlgetnode

NAMESTATUSROLESAGEVERSION

masterNotReadymaster48mvl.20.1

##發(fā)現節(jié)點STATUS是NotReady的，是因為沒有配置網絡

6.4配置網絡

使用以下命令安裝Calico網絡

wgethttps://docs.projectcalico,org/manifests/calico.yaml

##編輯calico,yaml

##修改calico,yaml文件設置指定的網卡

#Clustertypetoidentifythedeploymenttype

-name:CLUSTER_TYPE

value:〃k8s,bgp〃

#IPautomaticdetection

-name:IP_AUTODETECTION_METHOD

value:〃interface=en.*〃

#Auto-detecttheBGPIPaddress.

-name:IP

value:/zautodetectz，

#EnableIPIP

-name:CALIC0_IPV4P00L_IPIP

value:"Never”

##構建calico網絡

kubectlapply-f

此時查看node信息，master的狀態(tài)已經是Ready了.

[root@master~]$kubectlgetnode

NAMESTATUSROLESAGEVERSION

masterReadymaster48mvl.20.5

看到STATUS是Ready的，說明網絡已經通了。

七、追加Node節(jié)點

##到其他幾個node節(jié)點進行執(zhí)行即可

kubeadmjoin192.168.3.10:6443—tokenabcdef.0123456789abcdef\

-discovery-token-ca-cert-hash

sha256:37eb59b3459a1651222a98e35d057cfd102e8ae311c5fc9bb4be22cd46a59c

29

八、驗證狀態(tài)

[root@kmaster、]#kubectlgetnode

NAMESTATUSROLESAGEVERSION

kmasterReadycontrol-plane,master26mvl.20.5

kworkerlReady<none>5m37svl.20.5

kworker2Ready<none>5m28svl.20.5

[root@kmasterkubectlgetpod-nkube-system-0wide

##如果看到下面的pod狀態(tài)都是Running狀態(tài)，說明K8S集群環(huán)境就構建完成

附錄

kubectldeletenode-all#刪除所有的節(jié)點

kubeadmreset-f#重置kubeadm

modprobe-ripip

Ismod

rm-rf~/,kube/

rm-rf/etc/kubernetes/

rm-rf/etc/systemd/system/kubelet.service,d

rm-rf/etc/systemd/system/kubelet.service

rm-rf/usr/bin/kube*

rm-rf/etc/cni

rm-rf/opt/cni

rm-rf/var/lib/etcd

rm-rf/var/etcd

yumremovekube*

apiVersion:apps/vl#指定api版本，此值必須在kubectlapi-versions

中

kind:Deployment#指定創(chuàng)建資源的角色/類型

metadata:#資源的元數據/屬性

name:demo#資源的名字，在同一個namespace中必須唯一

namespace:defaultit部署在哪個namespace中

labels:#設定資源的標簽

app:demo

version:stable

spec:#資源規(guī)范字段

replicas:1#聲明副本數目

revisionHistoryLimit:3#保留歷史版本

selector:#選擇器

matchLabels:#匹配標簽

app:demo

version:stable

strategy:#策略

rollingUpdate:#滾動更新

maxSurge:30%#最大額外可以存在的副本數，可以為百分比，也可以

為整數

maxUnavailable:30%#示在更新過程中能夠進入不可用狀態(tài)的Pod的

最大值，可以為百分比，也可以為整數

type:RollingUpdate#滾動更新策略

template:#模版

metadata:#資源的元數據/屬性

annotations:#自定義注解列表

sidecar,istio.io/inject:，zfalse，z#自定義注解名字

labels:#設定資源的標簽

app:demo

version:stable

spec:#資源規(guī)范字段

containers:

-name:demo#容器的名字

image:demo:vl#容器使用的鏡像地址

imagePulIPolicy:IfNotPresent#每次Pod啟動拉取鏡像策略，三

個選擇Always>Never>IfNotPresent

#Always,每次都檢查；Never,每

次都不檢查（不管本地是否有）；IfNotPresent,如果本地有就不檢查，如果

沒有就拉?。ㄊ謩訙y試時，

#已經打好鏡像存在docker容器中

時，使用存在不檢查級別，

#默認為每次都檢查，然后會進行

拉取新鏡像，因鏡像倉庫不存在，導致部署失敗）

resources:#資源管理

limits:#最大使用

cpu:300m#CPU,1核心=1000m

memory:500Mi#內存，1G=lOOOMi

requests:#容器運行時，最低資源需求，也就是說最少需要多少

資源容器才能正常運行

cpu:100m

memory:100Mi

livenessProbe:#pod內部健康檢查的設置

httpGet:#通過httpget檢查健康，返回200-399之間，則認為容

器正常

path:/healthCheck#URI地址

port:8080#端口

scheme:HTTP#協議

#host:127.0.0.1#主機地址

initialDelaySeconds:30#表明第一次檢測在容器啟動后多長時

間后開始

timeoutSeconds:5#檢測的超時時間

periodSeconds:30#檢查間隔時間

successThreshold:1#成功門檻

failureThreshold:5#失敗門檻，連接失敗5次，pod殺掉，重

啟一個新的pod

readinessProbe:#Pod準備服務健康檢查設置

httpGet:

path:/healthCheck

port:8080

scheme:HTTP

initialDelaySeconds:30

timeoutSeconds:5

periodSeconds:10

successThreshold:1

failureThreshold:5

#也可以用這種方法

#exec:執(zhí)行命令的方法進行監(jiān)測，如果其退出碼不為3則認為容器

正常

#command:

#-cat

it-/tmp/health

#也可以用這種方法

tttcpSocket:#通過tcpSocket檢查健康

#port:number

ports:

-name:http#名稱

containerPort:8080#容器開發(fā)對外的端口

protocol:TCP#協議

imagePulISecrets:#鏡像倉庫拉取密鑰

-name:harbor-certification

affinity:#親和性調試

nodeAffinity:#節(jié)點親和力

requiredDuringSchedulinglgnoredDuringExecution:#pod必須

部署到滿足條件的節(jié)點上

nodeSelectorTerms:#節(jié)點滿足任何一個條件就可以

-matchExpressions:#有多個選項，則只有同時滿足這些邏輯

選項的節(jié)點才能運行pod

-key:beta,kubernetes.io/arch

operator:In

values:

-amd64

apiVersion:vl#指定api版本，此值必須在kubectlapi-versions中

kind:Service#指定創(chuàng)建資源的角色/類型

metadata:#資源的元數據/屬性

name:demo#資源的名字，在同一個namespace中必須唯一

namespace:default#部署在哪個namespace中

labels:#設定資源的標簽

app:demo

spec:#資源規(guī)范字段

type:ClusterIP#ClusterIP類型

ports:

-port:8080#service端口

targetPort:http#pod端口容器暴露的端口

protocol:TCP#協議

name:http#端口名稱

nodePort:31319#對外訪問端口

selector:#選擇器

app:demo

K8s中暴露服務的方式

1.1>ClusterIP

該方式適用于Kubernetes1.10

ClusterIP服務是Kubernetes的默認服務。它給你一個集群內的服務，集群

內的其它應用都可以訪問該服務。集群外部無法訪問它。

ClusterIP服務的YAML文件類似如下:

apiVersion:vl

kind:Service

metadata:

name:my-internal-service

selector:

app:mynginx

spec:

type:ClusterIP

ports:

-name:http

port:80

targetPort:80

protocol:TCP

如果從Internet沒法訪問ClusterIP服務，那么我們?yōu)槭裁匆懻撍兀?/p>

那是因為我們可以通過Kubernetes的proxy模式來訪問該服務！

啟動Kubernetesproxy模式:

kubectlproxy-port=0

這樣你可以通過KubernetesAPI,使用如下模式來訪問這個服務:

1.http:〃localhost:37137/api/vl/proxy/namesDaces//services/:/

要訪問我們上面定義的服務，你可以使用如下地址:

1.http://localhost:37137/api/v3/proxy/namespaces/defacilt/services/my-intemal-

servicahttp/

何時使用這種方式？

有一些場景下，你得使用Kubernetes的proxy模式來訪問你的服務：

?由于某些原因，你需要調試你的服務，或者需要直接通過筆記本電腦去訪問它們。

?允許內部通信，展示內部儀表盤等。

這種方式要求我們運行kubectl作為一個未認證的用戶，因此我們不能用這種

方式把服務暴露到internet或者在生產環(huán)境使用。

1.2、NodePort

NodePort服務是引導外部流量到你的服務的最原始方式。NodePort,正如這個

名字所示，在所有節(jié)點（虛擬機）上開放一個特定端口，任何發(fā)送到該端口的

流量都被轉發(fā)到對應服務。

NodePort服務的YAML文件類似如下:

apiVersion:vl

kind:Service

metadata:

name:my-nodeport-service

selector:

app:my-app

spec:

type:NodePort

ports:

-name:http

port:80

targetPort:80

nodePort:30036

protocol:TCP

NodePort服務主要有兩點區(qū)別于普通的"ClusterIP"服務。第一,它的類型

是“NodePort”。有一個額外的端口，稱為nodePort,它指定節(jié)點上開放的端

口值。如果你不指定這個端口，系統將選擇一個隨機端口。大多數時候我們應

該讓Kubernetes來選擇端口，用戶自己來選擇可用端口代價太大。

何時使用這種方式？

1.這種方法有許多缺點：

2.每個端口只能是一種服務

3.端口范圍只能是30000-32767

如果節(jié)點/VM的IP地址發(fā)生變化，你需要能處理這種情況

基于以上原因，我不建議在生產環(huán)境上用這種方式暴露服務。如果你運行的服

務不要求一直可用，或者對成本比較敏感，你可以使用這種方法。這樣的應用

的最佳例子是demo應用，或者某些臨時應用。

1.3>LoadBalancer

LoadBalancer服務是暴露服務到internet的標準方式。在GKE上，這種方

式會啟動一個NetworkLoadBalancer[2],它將給你一個單獨的IP地址，轉

發(fā)所有流量到你的服務。

goadB陶nce「

elder

何時使用這種方式？

如果你想要直接暴露服務，這就是默認方式。所有通往你指定的端口的流量都

會被轉發(fā)到對應的服務。它沒有過濾條件，沒有路由等。這意味著你幾乎可以

發(fā)送任何種類的流量到該服務，像HTTP,TCP,UDP,Websocket,gRPC或其它

任意種類。

這個方式的最大缺點是每一個用LoadBalancer暴露的服務都會有它自己的IP

地址，每個用到的LoadBalancer都需要付費，這將是非常昂貴的。

1.4、Ingress

有別于以上所有例子，Ingress事實上不是一種服務類型。相反，它處于多個

服務的前端，扮演著“智能路由”或者集群入口的角色。

你可以用Ingress來做許多不同的事情，各種不同類型的Ingress控制器也

有不同的能力。

GKE上的默認ingress控制器是啟動一個HTTP(S)LoadBalancer[3]□它允

許你基于路徑或者子域名來路由流量到后端服務。例如，你可以將任何發(fā)往域

名foo.yourdomain.com的流量轉到foo服務，將路徑

yourdomain.com/bar/path的流量轉到bar服務。

Traffic

GKE上用L7HTTPLoadBalancer[4]生成的Ingress對象的YAML文件類似

如下：

apiVersion:extensions/vlbetal

kind:Ingress

metadata:

name:my-ingress

spec:

backend:

serviceName:other

servicePort:8080

rules:

-host:foo.mydomain.com

http:

paths:

-backend:

serviceName:foo

servicePort:8080

-host:mydomain.com

http:

paths:

-path:/bar/*

backend:

serviceName:bar

servicePort:8080

何時使用這種方式？

Ingress可能是暴露服務的最強大方式，但同時也是最復雜的。Ingress控制

器有各種類型，包括GoogleCloudLoadBalancer,Nginx,Contour,

Istio,等等。它還有各種插件，比如cert-manager[5],它可以為你的服務自

動提供SSL證書。

如果你想要使用同一個IP暴露多個服務，這些服務都是使用相同的七層協議

（典型如HTTP）,那么Ingress就是最有用的。如果你使用本地的GCP集

成，你只需要為一個負載均衡器付費，且由于Ingress是“智能”的，你還可

以獲取各種開箱即用的特性（比如SSL、認證、路由等等）。

Ingress服務暴露實操

1、拉取鏡像

dockerpullpollyduan/ingress-nginx-controller:v0.45.0

2、修改鏡像名稱

dockertagpollyduan/ingress-nginx-controller:vO.45.0

k8s.ger.io/ingress-nginx/controller:vO.45.0

3、準備yaml文件

apiVersion:vl

kind:Namespace

metadata:

name:ingress-nginx

labels:

app.kubernetes.io/name:ingress-nginx

app.kubernetes.io/instance:ingress-nginx

#Source:ingress-ng