目录
一 搭建环境准备
二 搭建步骤
三 pod简介
3.1 pod介绍
3.2 pod配置
3.3 pod生命周期
3.4 pod调度
一 搭建环境准备
1.1 关闭防火墙和selinux，有自己搭建好的harbor仓库
1.2 先禁用服务器的交换分区（如果服务器内存不够，k8s使用交换分区充当内存的话，有可能会降低容器的运行效率）
systemctl mask swap.target
swapoff -a
sed -i 's/.*swap.*/# &/' /etc/fstab
1.3 然后在各个节点上做hosts解析（用到几个节点做几个）
vim /etc/hosts
172.25.254.100 master
172.25.254.10 node1
172.25.254.20 node2
1.4 配置时间同步服务器
yum install chronyd
systemctl start chronyd
sed -i '3,6 s/^/# /' /etc/chrony.conf
sed -i '6 a server ntp.aliyun.com iburst' /etc/chrony.conf
systemctl restart chronyd.service
chronyc sources
systemctl restart chronyd
二 搭建步骤
2.1 安装docker
配置docker源（上面是docker源，下面是docker需要的依赖源）
vim /etc/yum.repos.d/docker.repo
[docker]
name=docker-ce
baseurl=https://mirrors.tuna.tsinghua.edu.cn/docker-ce/linux/centos/7/x86_64/stable/
gpgcheck=0
[centos]
name=extras
baseurl=https://mirrors.aliyun.com/centos/7.9.2009/extras/x86_64
gpgcheck=0
2.2 下载
yum makecache
yum install docker-ce
创建目录
cd /etc/ docker/
vim daemon.json
将你的harbor地址写里面，下面是我的
写了然后重新加载
systemctl daemon-reload
systemctl restart docker
测试登录：
2.3 下载安装所需包
cd /etc/yum.repos.d/
vim k8s.repo
[k8s]
name=k8s
baseurl=https://mirrors.aliyun.com/Kubernetes-new/core/stable/v1.30/rpm
gpgcheck=0
yum clean all
yum makecache
2.3.1 因为需要cri-docker所以还需cri-docker
还有他所需的依赖包
因为他需要libcgroup-0.41-19.el7.x86_64 环境
所以 yum whatprovides libcgroup（查所需下载包）
Yum install libcgroup-0.41-21.el7.x86_64
然后安装cri-docker
yum install cri-dockerd-0.3.14-3.el7.x86_64.rpm
systemctl stop docker
systenctl start cri-docker
systemctl status cri-docker
2.4 在指定cri-docker中指定harbor的根容器和网络
vim /lib/systemd/system/cri-docker.service
systemctl daemon-reload
systemctl restart cri-docker
2.5 在阿里云拉取镜像
kubeadm config images pull --image-repository registry.aliyuncs.com/google_containers --kubernetes-version v1.30.0 --cri-socket=unix:///var/run/cri-dockerd.sock
然后放进自己的harbor仓库中(需要提前在harbor仓库建立k8s的项目，且是公开级别的)
docker images | awk '/google/{ print $1":"$2}' \
| awk -F "/" '{system("docker tag "$0" xxx/k8s/"$3)}'
然后推进harbor
docker images | awk '/k8s/{system("docker push "$1":"$2)}'
2.6 部署k8s
systemctl start kubelet
kubeadm init --pod-network-cidr=10.244.0.0/16 --image-repository 172.25.254.11:800/k8s_stable --kubernetes-version v1.30.0 --cri-socket=unix:///var/run/cri-dockerd.sock
然后根据提示指定配置文件地址
echo "export KUBECONFIG=/etc/kubernetes/admin.conf" >> ~/.bash_profile
然后修改上传的yaml文件内容
vim kube-flannel.yml
使用/image 搜索其存在的位置，并且改变他的镜像目的地址
总共有三个我只截其中一个地方进行展示
然后在harbor仓库建立相关项目，将flannel镜像传入（用公开项目）
将镜像先放在docker里
docker load -i flannel-0.25.5.tag.gz
docker tag flannel/flannel-cni-plugin:v1.5.1-flannel1 xxx/flannel/flannel-cni-plugin:v1.5.1-flannel1
docker push xxx/flannel/flannel-cni-plugin:v1.5.1-flannel1
然后使用命令应用
kubectl apply -f kube-flannel.yml
然后master节点部署成功因为node1没开机所以没成功
node节点需要什么操作呢？
控制node节点，将需要的包，全拷到node节点内，我就拿一个节点作为演示
Node节点需要安装cri-docker
然后再文件里面指定根容器
然后如果不知道node加入master的token的话就重新生成一个
kubeadm token create --print-join-command
然后加入
kubeadm join 172.25.254.100:6443 --token uugax3.xw2qr346ppt54ysp --discovery-token-ca-cert-hash
sha256:6cc9c0127d2fdd8c4550422c000d4d19aa418b543b8e9d9a21e2105ff27cc5e9 --cri-socket=unix:///var/run/cri-dockerd.sock
然后node就会添加成功，和上图结果一样
三 pod简介
3.1 pod介绍
3.2 pod配置
下面是pod资源清单
apiVersion: v1 #必选，版本号，例如v1
kind: Pod #必选，资源类型，例如 Pod
metadata: #必选，元数据
name: string #必选，Pod名称
namespace: string #Pod所属的命名空间,默认为"default"
labels: #自定义标签列表
- name: string
spec: #必选，Pod中容器的详细定义
containers: #必选，Pod中容器列表
- name: string #必选，容器名称
image: string #必选，容器的镜像名称
imagePullPolicy: [ Always|Never|IfNotPresent ] #获取镜像的策略
command: [string] #容器的启动命令列表，如不指定，使用打包时使用的启动命令
args: [string] #容器的启动命令参数列表
workingDir: string #容器的工作目录
volumeMounts: #挂载到容器内部的存储卷配置
- name: string #引用pod定义的共享存储卷的名称，需用volumes[]部分定义的的卷名
mountPath: string #存储卷在容器内mount的绝对路径，应少于512字符
readOnly: boolean #是否为只读模式
ports: #需要暴露的端口库号列表
- name: string #端口的名称
containerPort: int #容器需要监听的端口号
hostPort: int #容器所在主机需要监听的端口号，默认与Container相同
protocol: string #端口协议，支持TCP和UDP，默认TCP
env: #容器运行前需设置的环境变量列表
- name: string #环境变量名称
value: string #环境变量的值
resources: #资源限制和请求的设置
limits: #资源限制的设置
cpu: string #Cpu的限制，单位为core数，将用于docker run --cpu-shares参数
memory: string #内存限制，单位可以为Mib/Gib，将用于docker run --memory参数
requests: #资源请求的设置
cpu: string #Cpu请求，容器启动的初始可用数量
memory: string #内存请求,容器启动的初始可用数量
lifecycle: #生命周期钩子
postStart: #容器启动后立即执行此钩子,如果执行失败,会根据重启策略进行重启
preStop: #容器终止前执行此钩子,无论结果如何,容器都会终止
livenessProbe: #对Pod内各容器健康检查的设置，当探测无响应几次后将自动重启该容器
exec: #对Pod容器内检查方式设置为exec方式
command: [string] #exec方式需要制定的命令或脚本
httpGet: #对Pod内个容器健康检查方法设置为HttpGet，需要制定Path、port
path: string
port: number
host: string
scheme: string
HttpHeaders:
- name: string
value: string
tcpSocket: #对Pod内个容器健康检查方式设置为tcpSocket方式
port: number
initialDelaySeconds: 0 #容器启动完成后首次探测的时间，单位为秒
timeoutSeconds: 0 #对容器健康检查探测等待响应的超时时间，单位秒，默认1秒
periodSeconds: 0 #对容器监控检查的定期探测时间设置，单位秒，默认10秒一次
successThreshold: 0
failureThreshold: 0
securityContext:
privileged: false
restartPolicy: [Always | Never | OnFailure] #Pod的重启策略
nodeName: <string> #设置NodeName表示将该Pod调度到指定到名称的node节点上
nodeSelector: obeject #设置NodeSelector表示将该Pod调度到包含这个label的node上
imagePullSecrets: #Pull镜像时使用的secret名称，以key：secretkey格式指定
- name: string
hostNetwork: false #是否使用主机网络模式，默认为false，如果设置为true，表示使用宿主机网络
volumes: #在该pod上定义共享存储卷列表
- name: string #共享存储卷名称 （volumes类型有很多种）
emptyDir: {} #类型为emtyDir的存储卷，与Pod同生命周期的一个临时目录。为空值
hostPath: string #类型为hostPath的存储卷，表示挂载Pod所在宿主机的目录
path: string #Pod所在宿主机的目录，将被用于同期中mount的目录
secret: #类型为secret的存储卷，挂载集群与定义的secret对象到容器内部
scretname: string
items:
- key: string
path: string
configMap: #类型为configMap的存储卷，挂载预定义的configMap对象到容器内部
name: string
items:
- key: string
path: string
# 创建Pod
[root@master pod]# kubectl apply -f pod-base.yaml
pod/pod-base created# 查看Pod状况
# READY 1/2 : 表示当前Pod中有2个容器，其中1个准备就绪，1个未就绪
# RESTARTS : 重启次数，因为有1个容器故障了，Pod一直在重启试图恢复它
[root@master pod]# kubectl get pod -n dev
NAME READY STATUS RESTARTS AGE
pod-base 1/2 Running 4 95s# 可以通过describe查看内部的详情
# 此时已经运行起来了一个基本的Pod，虽然它暂时有问题
[root@master pod]# kubectl describe pod pod-base -n dev
资源配额
容器中的程序要运行，肯定是要占用一定资源的，比如cpu和内存等，如果不对某个容器的资源做限制，那么它就可能吃掉大量资源，导致其它容器无法运行。针对这种情况，kubernetes提供了对内存和cpu的资源进行配额的机制，这种机制主要通过resources选项实现，他有两个子选项：
可以通过上面两个选项设置资源的上下限。
apiVersion: v1
kind: Pod
metadata:
name: pod-resources
namespace: dev
spec:
containers:
- name: nginx
image: nginx:1.17.1
resources: # 资源配额
limits: # 限制资源（上限）
cpu: "2" # CPU限制，单位是core数
memory: "10Gi" # 内存限制
requests: # 请求资源（下限）
cpu: "1" # CPU限制，单位是core数
memory: "10Mi" # 内存限制
3.3 pod生命周期
在整个生命周期中，Pod会出现5种状，分别如下：
挂起（Pending）：apiserver已经创建了pod资源对象，但它尚未被调度完成或者仍处于下载镜像的过程中
运行中（Running）：pod已经被调度至某节点，并且所有容器都已经被kubelet创建完成
成功（Succeeded）：pod中的所有容器都已经成功终止并且不会被重启
未知（Unknown）：apiserver无法正常获取到pod对象的状态信息，通常由网络通信失败所导致
创建和终止
pod的创建过程
用户通过kubectl或其他api客户端提交需要创建的pod信息给apiServer
apiServer开始生成pod对象的信息，并将信息存入etcd，然后返回确认信息至客户端
apiServer开始反映etcd中的pod对象的变化，其它组件使用watch机制来跟踪检查apiServer上的变动
scheduler发现有新的pod对象要创建，开始为Pod分配主机并将结果信息更新至apiServer
apiServer将接收到的pod状态信息存入etcd中
pod的终止过程
用户向apiServer发送删除pod对象的命令
apiServcer中的pod对象信息会随着时间的推移而更新，在宽限期内（默认30s），pod被视为dead
将pod标记为terminating状态
kubelet在监控到pod对象转为terminating状态的同时启动pod关闭过程
端点控制器监控到pod对象的关闭行为时将其从所有匹配到此端点的service资源的端点列表中移除
如果当前pod对象定义了preStop钩子处理器，则在其标记为terminating后即会以同步的方式启动执行
pod对象中的容器进程收到停止信号
宽限期结束后，若pod中还存在仍在运行的进程，那么pod对象会收到立即终止的信号
kubelet请求apiServer将此pod资源的宽限期设置为0从而完成删除操作，此时pod对于用户已不可见
容器探测
容器探测用于检测容器中的应用实例是否正常工作，是保障业务可用性的一种传统机制。如果经过探测，实例的状态不符合预期，那么kubernetes就会把该问题实例" 摘除 "，不承担业务流量。kubernetes提供了两种探针来实现容器探测，分别是：
liveness probes：存活性探针，用于检测应用实例当前是否处于正常运行状态，如果不是，k8s会重启容器
readiness probes：就绪性探针，用于检测应用实例当前是否可以接收请求，如果不能，k8s不会转发流量
重启策略
出现问题kubernetes就会对容器所在的Pod进行重启，其实这是由pod的重启策略决定的，pod的重启策略有 3 种，分别如下：
重启策略适用于pod对象中的所有容器，首次需要重启的容器，将在其需要时立即进行重启，随后再次需要重启的操作将由kubelet延迟一段时间后进行，且反复的重启操作的延迟时长以此为10s、20s、40s、80s、160s和300s，300s是最大延迟时长。
3.4 pod调度
Pod调度
在默认情况下，一个Pod在哪个Node节点上运行，是由Scheduler组件采用相应的算法计算出来的，这个过程是不受人工控制的。但是在实际使用中，这并不满足的需求，因为很多情况下，我们想控制某些Pod到达某些节点上，那么应该怎么做呢？这就要求了解kubernetes对Pod的调度规则，kubernetes提供了四大类调度方式：
自动调度：运行在哪个节点上完全由Scheduler经过一系列的算法计算得出
定向调度：NodeName、NodeSelector
亲和性调度：NodeAffinity、PodAffinity、PodAntiAffinity
污点（容忍）调度：Taints、Toleration
