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

K8s的介绍和架构

一.什么是kubernetes

Kubernetes(k8s)是Google开源的容器集群管理系统(谷歌内部:Borg),

目前已经成为容器编排一个标准。在Docker技术的基础上，为容器化的应用提

供部署运行、资源调度、服务发现和动态伸缩、高可用等一系列完整功能，提

高了大规模容器集群管理的便捷性。

Kubernetes优势:

，容器编排

-轻量级

-开源

-弹性伸缩

-负载均衡

二、Kubernetes架构和组件

•用户通过kubectl提交需要运行的docker

container(pod)

•apiserver把请求存储在etcd里面

•scheduler扫描,分配机器

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

在本机上运行

•用户提交RC描述,replication

controller监视集群中的容器并保持数量

•用户提交service描述文件，由kube

proxy负责具体的工作流量转发

2.1核心组件

2.1.1KubernetesMaster控制组件，调度管理整个系统(集群)，包含如下

组件：

a、KubernetesAPIServer

作为Kubernetes系统的入口，其封装了核心对象的增删改查操作，以

RESTfulAPI接口方式提供给外部客户和内部组件调用。它是系统管理指令的

统一入口，任何对资源进行增删改查的操作都要交给APIServer处理后再提交

给etcdokubectl是直接和APIServer交互的。

a,提供了资源对象的唯一操作入口，其他所有组件都必须通过它提供的API来

操作资源数据，只有APIServer与存储通信，其他模块通过APIServer访问

集群状态。实现集群故障检测和恢复的自动化工作，负责执行各种控制器，主

要有：

第一，是为了保证集群状态访问的安全。

第二，是为了隔离集群状态访问的方式和后端存储实现的方式：APIServer

是状态访问的方式，不会因为后端存储技术etcd的改变而改变。

b,作为kubernetes系统的入口，封装了核心对象的增删改查操作，以

RESTFul接口方式提供给外部客户和内部组件调用。对相关的资源数据“全量

查询”+“变化监听”，实时完成相关的业务功能

b、KubernetesScheduler

为新建立的Pod进行节点（node）选择（即分配机器）,**负责集群的资源调度

**。组件抽离，可以方便替换成其他调度器。

a,Scheduler收集和分析当前Kubernetes集群中所有Minion/Node节点的资源

（内存、CPU）负载情况，然后依此分发新建的Pod到Kube门）etes集群中可用的

节点。

b,实时监测Kubernetes集群中未分发和已分发的所有运行的Pod。

c,Scheduler也监测Minion/Node节点信息，由于会频繁查找Minion/Node节

点，Scheduler会缓存一份最新的信息在本地。

d,Scheduler在分发Pod到指定的Minion/Node节点后，会把Pod相关的信息

Binding写回APIServer。

c、KubernetesController

负责执行各种控制器，目前已经提供了很多控制器来保证Kubernetes的正常运

行。

-ReplicationController

管理维护ReplicationController,关联ReplicationController

和Pod,保证ReplicationController定义的副本数量与实际运行Pod数量一

致。

-NodeController

管理维护Node,定期检查Node的健康状态，标识出（失效|未失效）的

Node节点。

-NamespaceController

管理维护Namespace,定期清理无效的Namespace,包括Namesapce下

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

-ServiceController

管理维护Service,提供负载以及服务代理。

-EndPointsController

管理维护Endpoints,关联Service和Pod,创建Endpoints为

Service的后端，当Pod发生变化时，实时更新Endpoints。

-ServiceAccountController

管理维护ServiceAccount,为每个Namespace创建默认的Service

Account,同时为ServiceAccount仓Ll建ServiceAccountSecreto

-PersistentVolumeController

管理维护PersistentVolume和PersistentVolumeClaim,为新的

PersistentVolumeClaim分配PersistentVolume进行绑定，为释放的

PersistentVolume执行清理回收。

-DaemonSetController

管理维护DaemonSet,负责创建DaemonPod,保证指定的Node上正

常的运行DaemonPod。

-DeploymentController

管理维护Deployment,关联Deployment和Replication

Controller,保证运行指定数量的Pod。当Deployment更新时，控制实现

ReplicationController和Pod的更新。

-JobController

管理维护Job,为Jod创建一次性任务Pod,保证完成Job指定完成的

任务数目

-PodAutoscalerController

实现Pod的自动伸缩，定时获取监控数据，进行策略匹配，当满足条

件时执行Pod的伸缩动作。

2.1.2KubernetesNode运行节点，运行管理业务容器，包含如下组件：

a、Kubelet

负责管控容器，Kubelet会从KubernetesAPIServer接收Pod的创建请

求，启动和停止容器，监控容器运行状态并汇报给KubernetesAPIServero

b、KubernetesProxy

负责为Pod创建代理服务，KubernetesProxy会从KubernetesAPIServer

获取所有的Service信息，并根据Service的信息创建代理服务，实现

Service到Pod的请求路由和转发，从而实现Kubernetes层级的虚拟转发网

络。该模块实现了Kubernetes中的服务发现和反向代理功能。

反向代理方面:kube-proxy支持TCP和UDP连接转发，默认基于RoundRobin

算法**将客户端流量转发到与service对应的一组后端pod。

**服务发现方面：kube-proxy使用etcd的watch机制，监控集群中service

和endpoint对象数据的动态变化，并且维护一个service到endpoint的映射

关系，从而保证了后端pod的IP变化不会对访问者造成影响。另外kube-

proxy还支持sessionaffinityo

c、Docker

Node上需要运行容器服务。

2.1.3master和node之外的组件：

a、etcd

一个高可用的K/V键值对存储和服务发现系统，etcd的功能是给flannel提供

数据存储，可以单机部署或者集群部署。

b、flannel

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

主流来进行部署。**所有node节点上的docker启动的时候需要flannel分发

IP地址，而flannel就会去请求etcd中的配置，各个node分配不同的IP网

段，类似于咱路由器DHCP的功能，这样就有效的避免了IP地址的冲突，同时

flannel对docker容器的数据包进行转发到另一个node节点上，flannel服

务这样就实现了整个K8S集群中docker容器网络互通问题。**

kubernetes基本概念

Cluster

Cluster是计算、存储和网络资源的集合，Kubernetes利用这些资源运行各种

基于容器的应用。

Master

Master是Cluster的大脑，它的主要职责是调度，即决定将应用放在哪里运

行。Master运行在Linux操作系统，可以是物理机或者虚拟机。为了实现高可

用，可以运行多个Master。

Node

Node的指责是运行容器应用。Node由Master管理，Node负责监控并汇报容器

的状态，并根据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通常不会直接创建Pod,而是通过Controller来管理Pod的。

Controller中定义了Pod的部署特性，比如有几个副本，在什么样的Node上

运行等。为了满足不同的业务场景，Kubernetes提供了多种Controller,包括

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

最常用的Controller,比如前面就是通过Deployment来部署应用的。

Deployment可以管理Pod的多个副本，并确保Pod按照期望的状态运行。

ReplicaSet实现了Pod的多副本管理。使用Deployment时会自动创建

ReplicaSet,也就是说Deployment是通过ReplicaSet来管理Pod的多个副

本，我们通常不需要直接使用ReplicaSet。DaemonSet用于每个Node最多只运

行一个Pod副本的场景。正如其名称所揭示的，DaemonSet通常用于运行

daemonoStatefuleSet能够保证Pod的每个副本在整个生命周期中名称是不变

的。而其他Controller不提供这个功能，当某个Pod发生故障需要删除并重新

启动时，Pod的名称会发生变化。同时StatefuleSet会保证副本按照固定的顺

序启动、更新或者删除。Job用于运行结束就删除的应用。而其他Controller

中的Pod通常是长期持续运行。

复制控制器(ReplicationController,RC)

RC是K8s集群中最早的保证Pod高可用的API对象。通过监控运行中的Pod来

保证集群中运行指定数目的Pod副本。指定的数目可以是多个也可以是1个；

少于指定数目，RC就会启动运行新的Pod副本；多于指定数目，RC就会杀死多

余的Pod副本。即使在指定数目为1的情况下，通过RC运行Pod也比直接运行

Pod更明智，因为RC也可以发挥它高可用的能力，保证永远有1个Pod在运

行。RC是K8s较早期的技术概念，只适用于长期伺服型的业务类型，比如控制

小机器人提供高可用的Web服务。

副本集(ReplicaSet,RS)

RS是新一代RC,提供同样的高可用能力，区别主要在于RS后来居上，能支持

更多种类的匹配模式。副本集对象一般不单独使用，而是作为Deployment的理

想状态参数使用。

部署(Deployment)

部署表示用户对K8s集群的一次更新操作。部署是一个比RS应用模式更广的

API对象，可以是创建一个新的服务，更新一个新的服务，也可以是滚动升级

一个服务。滚动升级一个服务，实际是创建一个新的RS,然后逐渐将新RS中

副本数增加到理想状态，将旧RS中的副本数减小到0的复合操作；这样一个复

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

以K8s的发展方向，未来对所有长期伺服型的的业务的管理，都会通过

Deployment来管理。

月艮务(Service)

Deployment可以部署多个副本，每个Pod都有自己的IP,外界如何访问这些副

本呢？通过Pod的IP吗？要知道Pod很可能会被频繁地销毁和重启，它们的

IP会发生变化，用IP来访问不太现实。答案是Service。Kubernetes

Service定义了外界访问一组特定Pod的方式。Service有自己的IP和端口，

Service为Pod提供了负载均衡。Kubernetes运行容器(Pod)与访问容器

(Pod)这两项任务分别由Controller和Service执行。RC、RS和Deployment

只是保证了支撑服务的微服务Pod的数量，但是没有解决如何访问这些服务的

问题。一个Pod只是一个运行服务的实例，随时可能在一个节点上停止，在另

一个节点以一个新的IP启动一个新的Pod,因此不能以确定的IP和端口号提

供服务。要稳定地提供服务需要服务发现和负载均衡能力。服务发现完成的工

作，是针对客户端访问的服务，找到对应的的后端服务实例。在K8s集群中，

客户端需要访问的服务就是Service对象。每个Service会对应一个集群内部

有效的虚拟IP,集群内部通过虚拟IP访问一个服务。在K8s集群中微服务的

负载均衡是由Kube-proxy实现的。Kube-proxy是K8s集群内部的负载均衡

器。它是一个分布式代理服务器，在K8s的每个节点上都有一个；这一设计体

现了它的伸缩性优势，需要访问服务的节点越多，提供负载均衡能力的Kube-

proxy就越多，高可用节点也随之增多。与之相比，我们平时在服务器端做个

反向代理做负载均衡，还要进一步解决反向代理的负载均衡和高可用问题。

Namespace

如果有多个用户或项目组使用同一个KubernetesCluster,如何将他们创建的

Controller＞Pod等资源分开呢？

答案就是Namespaceo

Namespace可以将一个物理的Cluster逻辑上划分成多个虚拟Cluster,每个

Cluster就是一个Namespaceo不同Namespace里的资源是完全隔离的。

Kubernetes默认创建了两个Namespace。

•default-创建资源时如果不指定，将被放到这个Namespace中。

•kube-system-Kubernetes自己创建的系统资源将放到这个Namespace中

K8s集群安装

一、环境准备

1.1机器环境

非常重要必须看咯

1、节点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

节点hostname作用IP

kmasterkmaster0

knodelkworkl1

knode2kwork22

1.2设置主机别名

[root@localhosthostnamectlset-hostnamekmaster-static

[root@localhosthostnamectlset-hostnamekworkerl-static

[root@localhosthostnamectlset-hostnamekworker2--static

1.3服务器静态IP配置

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

BOOTPROTO="static"#dhcp改为static

0NB00T="yes"#开机启用本配置

IPADDR=192.168.3.10#静态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安装依赖环境

注意：每一台机器都需要安装此依赖环境

yuminstall-yconntrackntpdatentpipvsadmipsetjqiptablescurl

sysstatlibseccompwgetvimnet-toolsgitiprouteIrzszbash­

completiontreebridge-utilsunzipbind-utilsgcc

1.7防火墙配置

安装iptables,启动iptables,设置开机自启，清空iptables规则，保存当

前规则到默认规则

#关闭防火墙(生产环境建议使用放行端口)

systemctlstopfirewalld&&systemctldisablefirewalld

#置空iptables

yum-yinstalliptables-services&&systemctlstartiptables&&

systemctlenableiptables&&iptables-F&&serviceiptablessave

1.8关闭selinux［必须操作］

因为在K8S集群安装的时候需要执行脚本，如果Selinux没有关闭它会阻止执

行。

#关闭swap分区【虚拟内存】并且永久关闭虚拟内存

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

#将优化内核文件拷贝到/etc/sysctl.d/文件夹下，这样优化文件开机的时候能

够被调用

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

#手动刷新，让优化文件立即生效

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

2.2调整系统临时区

#设置系统时区为中国/上海

timedatectlset-timezone〃Asia/Shanghai〃

#将当前的UTC时间写入硬件时钟

timedatectlset-local-rtc0

#重启依赖于系统时间的服务

systemctlrestartrsyslog

systemctlrestartcrond

2.3关闭系统不需要的服务

systemctlstoppostfix&&systemctldisablepostfix

2.4设置日志保存方式

2.4.1创建保存日志的目录

mkdir/var/1og/journal

2.4.2创建配置文件存放目录

mkdir/etc/systemd/journald.conf,d

2.4.3创建配置文件

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打开文件数调整（可忽略，不执行）

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

=二====二======执行结果================

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

#紧接着配置一个稳定的仓库、仓库配置会保存到/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文件

#创建/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

即可发现错误

#创建，存储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执行初始化

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

6.2验证是否成功

##如果在执行完成后出现下面的语句代表成功并记录下加入worker节点的

命令

kubeadmjoin192.168.3.10:6443-tokenabcdef.0123456789abcdef\

-discovery-token-ca-cert-hash

sha256:13aff92657d0f3451ac68e3200ebc3clc6ea6980blde700ba257adl538e0ce

3

6.3查看Master节点网络状态

##配置kubectl执行命令环境

mkdir-p$H0ME/.kube

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

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

##执行kubectl命令查看机器节点

kubectlgetnode

NAMESTATUSROLESAGEVERSION

masterNotReadymaster48mvl.20.1

##发现节点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的状态已经是Ready了.

[root@master~]$kubectlgetnode

NAMESTATUSROLESAGEVERSION

masterReadymaster48mvl.20.5

看到STATUS是Ready的，说明网络已经通了。

七、追加Node节点

##到其他几个node节点进行执行即可

kubeadmjoin192.168.3.10:6443—tokenabcdef.0123456789abcdef\

-discovery-token-ca-cert-hash

sha256:37eb59b3459a1651222a98e35d057cfd102e8ae311c5fc9bb4be22cd46a59c

29

八、验证状态

[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状态都是Running状态，说明K8S集群环境就构建完成

附录

kubectldeletenode-all#删除所有的节点

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#指定创建资源的角色/类型

metadata:#资源的元数据/属性

name:demo#资源的名字，在同一个namespace中必须唯一

namespace:defaultit部署在哪个namespace中

labels:#设定资源的标签

app:demo

version:stable

spec:#资源规范字段

replicas:1#声明副本数目

revisionHistoryLimit:3#保留历史版本

selector:#选择器

matchLabels:#匹配标签

app:demo

version:stable

strategy:#策略

rollingUpdate:#滚动更新

maxSurge:30%#最大额外可以存在的副本数，可以为百分比，也可以

为整数

maxUnavailable:30%#示在更新过程中能够进入不可用状态的Pod的

最大值，可以为百分比，也可以为整数

type:RollingUpdate#滚动更新策略

template:#模版

metadata:#资源的元数据/属性

annotations:#自定义注解列表

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

labels:#设定资源的标签

app:demo

version:stable

spec:#资源规范字段

containers:

-name:demo#容器的名字

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

imagePulIPolicy:IfNotPresent#每次Pod启动拉取镜像策略，三

个选择Always>Never>IfNotPresent

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

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

没有就拉取（手动测试时，

#已经打好镜像存在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:执行命令的方法进行监测，如果其退出码不为3则认为容器

正常

#command:

#-cat

it-/tmp/health

#也可以用这种方法

tttcpSocket:#通过tcpSocket检查健康

#port:number

ports:

-name:http#名称

containerPort:8080#容器开发对外的端口

protocol:TCP#协议

imagePulISecrets:#镜像仓库拉取密钥

-name:harbor-certification

affinity:#亲和性调试

nodeAffinity:#节点亲和力

requiredDuringSchedulinglgnoredDuringExecution:#pod必须

部署到满足条件的节点上

nodeSelectorTerms:#节点满足任何一个条件就可以

-matchExpressions:#有多个选项，则只有同时满足这些逻辑

选项的节点才能运行pod

-key:beta,kubernetes.io/arch

operator:In

values:

-amd64

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

kind:Service#指定创建资源的角色/类型

metadata:#资源的元数据/属性

name:demo#资源的名字，在同一个namespace中必须唯一

namespace:default#部署在哪个namespace中

labels:#设定资源的标签

app:demo

spec:#资源规范字段

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服务，那么我们为什么要讨论它呢？

那是因为我们可以通过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或者在生产环境使用。

1.2、NodePort

NodePort服务是引导外部流量到你的服务的最原始方式。NodePort,正如这个

名字所示，在所有节点（虚拟机）上开放一个特定端口，任何发送到该端口的

流量都被转发到对应服务。

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服务主要有两点区别于普通的"ClusterIP"服务。第一,它的类型

是“NodePort”。有一个额外的端口，称为nodePort,它指定节点上开放的端

口值。如果你不指定这个端口，系统将选择一个随机端口。大多数时候我们应

该让Kubernetes来选择端口，用户自己来选择可用端口代价太大。

何时使用这种方式？

1.这种方法有许多缺点：

2.每个端口只能是一种服务

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

如果节点/VM的IP地址发生变化，你需要能处理这种情况

基于以上原因，我不建议在生产环境上用这种方式暴露服务。如果你运行的服

务不要求一直可用，或者对成本比较敏感，你可以使用这种方法。这样的应用

的最佳例子是demo应用，或者某些临时应用。

1.3>LoadBalancer

LoadBalancer服务是暴露服务到internet的标准方式。在GKE上，这种方

式会启动一个NetworkLoadBalancer[2],它将给你一个单独的IP地址，转

发所有流量到你的服务。

goadB陶nce「

elder

何时使用这种方式？

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

会被转发到对应的服务。它没有过滤条件，没有路由等。这意味着你几乎可以

发送任何种类的流量到该服务，像HTTP,TCP,UDP,Websocket,gRPC或其它

任意种类。

这个方式的最大缺点是每一个用LoadBalancer暴露的服务都会有它自己的IP

地址，每个用到的LoadBalancer都需要付费，这将是非常昂贵的。

1.4、Ingress

有别于以上所有例子，Ingress事实上不是一种服务类型。相反，它处于多个

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

你可以用Ingress来做许多不同的事情，各种不同类型的Ingress控制器也

有不同的能力。

GKE上的默认ingress控制器是启动一个HTTP(S)LoadBalancer[3]□它允

许你基于路径或者子域名来路由流量到后端服务。例如，你可以将任何发往域

名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