一、kubernetes简介及部署方法
1.1kubernetes介绍
kubernetes是一个容器编排软件工具，除了它还有doker自带的容器编排工具Swarm、apche的一个资源统一管控工具mesos等
kubernetes
-
在Docker 作为高级容器引擎快速发展的同时，在Google内部，容器技术已经应用了很多年
-
Borg系统运行管理着成千上万的容器应用。
-
Kubernetes项目来源于Borg，可以说是集结了Borg设计思想的精华，并且吸收了Borg系统中的经验和教训。
-
Kubernetes对计算资源进行了更高层次的抽象，通过将容器进行细致的组合，将最终的应用服务交给用户。
kubernetes主要功能：
自我修复：一旦某一个容器崩溃，能够在1秒中左右迅速启动新的容器
弹性伸缩：可以根据需要，自动对集群中正在运行的容器数量进行调整
服务发现：服务可以通过自动发现的形式找到它所依赖的服务
负载均衡：如果一个服务起动了多个容器，能够自动实现请求的负载均衡
版本回退：如果发现新发布的程序版本有问题，可以立即回退到原来的版本
存储编排：可以根据容器自身的需求自动创建存储卷
1.2kubernetes架构
一个kubernetes集群主要是由控制节点(master)、工作节点(node)构成，每个节点上都会安装不同的组件
1.2.1k8s各个组件用途
1 master：集群的控制平面，负责集群的决策
-
ApiServer : 资源操作的唯一入口，接收用户输入的命令，提供认证、授权、API注册和发现等机制
-
Scheduler : 负责集群资源调度，按照预定的调度策略将Pod调度到相应的node节点上
-
ControllerManager : 负责维护集群的状态，比如程序部署安排、故障检测、自动扩展、滚动更新等
-
Etcd ：负责存储集群中各种资源对象的信息
2 node：集群的数据平面，负责为容器提供运行环境
-
kubelet：负责维护容器的生命周期，同时也负责Volume（CVI）和网络（CNI）的管理
-
Container runtime：负责镜像管理以及Pod和容器的真正运行（CRI）
-
kube-proxy：负责为Service提供cluster内部的服务发现和负载均衡
1.2.2k8s各组件之间的调用关系
当我们要运行一个web服务时
-
kubernetes环境启动之后，master和node都会将自身的信息存储到etcd数据库中
-
web服务的安装请求会首先被发送到master节点的apiServer组件
-
apiServer组件会调用scheduler组件来决定到底应该把这个服务安装到哪个node节点上
在此时，它会从etcd中读取各个node节点的信息，然后按照一定的算法进行选择，并将结果告知apiServer
-
apiServer调用controller-manager去调度Node节点安装web服务
-
kubelet接收到指令后，会通知docker，然后由docker来启动一个web服务的pod
-
如果需要访问web服务，就需要通过kube-proxy来对pod产生访问的代理
1.2.3k8s的常用名词概念
-
Master：集群控制节点，每个集群需要至少一个master节点负责集群的管控
-
Node：工作负载节点，由master分配容器到这些node工作节点上，然后node节点上的
-
Pod：kubernetes的最小控制单元，容器都是运行在pod中的，一个pod中可以有1个或者多个容器
-
Controller：控制器，通过它来实现对pod的管理，比如启动pod、停止pod、伸缩pod的数量等等
-
Service：pod对外服务的统一入口，下面可以维护者同一类的多个pod
-
Label：标签，用于对pod进行分类，同一类pod会拥有相同的标签
-
NameSpace：命名空间，用来隔离pod的运行环境
1.2.4 k8S的分层架构
-
核心层：Kubernetes最核心的功能，对外提供API构建高层的应用，对内提供插件式应用执行环境
-
应用层：部署（无状态应用、有状态应用、批处理任务、集群应用等）和路由（服务发现、DNS解析等）
-
管理层：系统度量（如基础设施、容器和网络的度量），自动化（如自动扩展、动态Provision等）以及策略管理（RBAC、Quota、PSP、NetworkPolicy等）
-
接口层：kubectl命令行工具、客户端SDK以及集群联邦
-
生态系统：在接口层之上的庞大容器集群管理调度的生态系统，可以划分为两个范畴
-
Kubernetes外部：日志、监控、配置管理、CI、CD、Workflow、FaaS、OTS应用、ChatOps等
-
Kubernetes内部：CRI、CNI、CVI、镜像仓库、Cloud Provider、集群自身的配置和管理等
环境部署：
这里用到是rhel9.1系统克隆出来的四台主机，一个是harbor主机。
[root@k8s-node1 ~]# vim /etc/hosts
172.25.254.10 k8s-node1
172.25.254.20 k8s-node2
172.25.254.100 k8s-master
172.25.254.250 reg.strongjcl.org
复制到其他三台上
[root@k8s-node1 ~]# scp /etc/hosts [email protected]:/etc/hosts
[root@k8s-node1 ~]# scp /etc/hosts [email protected]:/etc/hosts
[root@k8s-node1 ~]# scp /etc/hosts [email protected]:/etc/hosts
尝试看能不能ping通
[root@k8s-node1 ~]# ping k8s-node1
[root@k8s-node1 ~]# ping k8s-node2
[root@k8s-node1 ~]# ping k8s-master
安装docker
[root@k8s-node1 ~]# tar zxf docker.tar.gz
[root@k8s-node1 ~]# yum install *.rpm -y --allowerasing
创建一个放自身证书的目录
[root@k8s-node1 ~]# mkdir /etc/docker/certs.d/reg.strongjcl.org/ -p
[root@k8s-node1 ~]# vim /etc/docker/daemon.json
{
"registry-mirrors": ["https://reg.strongjcl.org"]
}
[root@k8s-node1 ~]# systemctl enable --now docker
查看docker信息
[root@k8s-node1 ~]# docker info
在harbor主机上重启harbor
[root@docker-hub harbor]# docker compose down
[root@docker-hub harbor]# docker compose up -d
把证书复制给10主机上
[root@docker-hub harbor]# scp /data/certs/strongjcl.org.crt [email protected]:/etc/docker/certs.d/reg.strongjcl.org/ca.crt
登录
[root@k8s-node1 ~]# docker login reg.strongjcl.org给20和100上配置
[root@k8s-node1 ~]# scp *.rpm [email protected]:/mnt
[root@k8s-node1 ~]# scp *.rpm [email protected]:/mnt
[root@k8s-node1 ~]# scp -r /etc/docker/ [email protected]:/etc/
[root@k8s-node1 ~]# scp -r /etc/docker/ [email protected]:/etc/
安装rpm包并重启docker就可以尝试登录拉取镜像了
二、k8s集群环境搭建
2.1k8s中容器的管理方式
K8S 集群创建方式有3种：
centainerd
默认情况下，K8S在创建集群时使用的方式
docker
Docker使用的普遍记录最高，虽然K8S在1.24版本后已经费力了kubelet对docker的支持，但时可以借助cri-docker方式来实现集群创建
cri-o
CRI-O的方式是Kubernetes创建容器最直接的一种方式，在创建集群的时候，需要借助于cri-o插件的方式来实现Kubernetes集群的创建。
2.2k8s集群部署
2.2.1环境说明
-
所有节点禁用selinux和防火墙
-
所有节点同步时间和解析
-
所有节点安装docker-ce
-
所有节点禁用swap，注意注释掉/etc/fstab文件中的定义
2.2.2 集群环境初始化
所有k8s集群节点执行以下步骤
2.2.2.1.所有禁用swap和本地解析
swapoff -a或者编辑/etc/fstab文件将以下内容注释
/dev/mapper/rhel-swap swap swap defaults 0 0
如果是企业7的系统还需要将所有节点设定dokcer的资源管理模式为systemd
[root@k8s-master ~]# vim /etc/docker/daemon.json
{
"registry-mirrors": ["https://reg.westos.org"],
"exec-opts": ["native.cgroupdriver=systemd"],
"log-driver": "json-file",
"log-opts": {
"max-size": "100m"
},
"storage-driver": "overlay2"
}2.2.2.2安装k8s部署工具
#部署软件仓库，添加K8S源
[root@k8s-master ~]# vim /etc/yum.repos.d/k8s.repo
[k8s]
name=k8s
baseurl=https://mirrors.aliyun.com/kubernetes-new/core/stable/v1.30/rpm
gpgcheck=0
#安装软件
[root@k8s-master ~]# dnf install kubelet-1.30.0 kubeadm-1.30.0 kubectl-1.30.0 -y2.2.2.3 设置kubectl命令补齐功能
[root@k8s-master ~]# dnf install bash-completion -y
[root@k8s-master ~]# echo "source <(kubectl completion bash)" >> ~/.bashrc
[root@k8s-master ~]# source ~/.bashrc2.2.2.4 在所节点安装cri-docker
k8s从1.24版本开始移除了dockershim，所以需要安装cri-docker插件才能使用docker
[root@k8s-master ~]# dnf install libcgroup-0.41-19.el8.x86_64.rpm \
> cri-dockerd-0.3.14-3.el8.x86_64.rpm -y
[root@k8s-master ~]# vim /lib/systemd/system/cri-docker.service
[Unit]
Description=CRI Interface for Docker Application Container Engine
Documentation=https://docs.mirantis.com
After=network-online.target firewalld.service docker.service
Wants=network-online.target
Requires=cri-docker.socket
[Service]
Type=notify
#指定网络插件名称及基础容器镜像
ExecStart=/usr/bin/cri-dockerd --container-runtime-endpoint fd:// --network-plugin=cni --pod-infra-container-image=reg.timinglee.org/k8s/pause:3.9
ExecReload=/bin/kill -s HUP $MAINPID
TimeoutSec=0
RestartSec=2
Restart=always
[root@k8s-master ~]# systemctl daemon-reload
[root@k8s-master ~]# systemctl start cri-docker
[root@k8s-master ~]# ll /var/run/cri-dockerd.sock
srw-rw---- 1 root docker 0 8月 26 22:14 /var/run/cri-dockerd.sock #cri-dockerd的套接字文件
2.2.2.5 在master节点拉取K8S所需镜像
#拉取k8s集群所需要的镜像
[root@k8s-master ~]# 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仓库
[root@k8s-master ~]# docker images | awk '/google/{ print $1":"$2}' \
| awk -F "/" '{system("docker tag "$0" reg.timinglee.org/k8s/"$3)}'
[root@k8s-master ~]# docker images | awk '/k8s/{system("docker push "$1":"$2)}'
2.2.2.6 集群初始化
#启动kubelet服务
[root@k8s-master ~]# systemctl status kubelet.service
#执行初始化命令
[root@k8s-master ~]# kubeadm init --pod-network-cidr=10.244.0.0/16 \
--image-repository reg.timinglee.org/k8s \
--kubernetes-version v1.30.0 \
--cri-socket=unix:///var/run/cri-dockerd.sock
#指定集群配置文件变量
[root@k8s-master ~]# echo "export KUBECONFIG=/etc/kubernetes/admin.conf" >> ~/.bash_profile
#当前节点没有就绪，因为还没有安装网络插件，容器没有运行
[root@k8s-master ~]# kubectl get node
NAME STATUS ROLES AGE VERSION
k8s-master.timinglee.org NotReady control-plane 4m25s v1.30.0
root@k8s-master ~]# kubectl get pod -A
NAMESPACE NAME READY STATUS RESTARTS AGE
kube-system coredns-647dc95897-2sgn8 0/1 Pending 0 6m13s
kube-system coredns-647dc95897-bvtxb 0/1 Pending 0 6m13s
kube-system etcd-k8s-master.timinglee.org 1/1 Running 0 6m29s
kube-system kube-apiserver-k8s-master.timinglee.org 1/1 Running 0 6m30s
kube-system kube-controller-manager-k8s-master.timinglee.org 1/1 Running 0 6m29s
kube-system kube-proxy-fq85m 1/1 Running 0 6m14s
kube-system kube-scheduler-k8s-master.timinglee.org 1/1 Running 0 6m29s2.2.2.7 安装flannel网络插件
#下载flannel的yaml部署文件
[root@k8s-master ~]# wget https://github.com/flannel-io/flannel/releases/latest/download/kube-flannel.yml
#现在镜像：
[root@k8s-master ~]# docker pull docker.io/flannel/flannel:v0.25.5
[root@k8s-master ~]# docekr docker.io/flannel/flannel-cni-plugin:v1.5.1-flannel1
#上传镜像到仓库
[root@k8s-master ~]# docker tag flannel/flannel:v0.25.5 \
reg.timinglee.org/flannel/flannel:v0.25.5
[root@k8s-master ~]# docker push reg.timinglee.org/flannel/flannel:v0.25.5
[root@k8s-master ~]# docker tag flannel/flannel-cni-plugin:v1.5.1-flannel1 \
reg.timinglee.org/flannel/flannel-cni-plugin:v1.5.1-flannel1
[root@k8s-master ~]# docker push reg.timinglee.org/flannel/flannel-cni-plugin:v1.5.1-flannel1
#编辑kube-flannel.yml 修改镜像下载位置
[root@k8s-master ~]# vim kube-flannel.yml
#需要修改以下几行
[root@k8s-master ~]# grep -n image kube-flannel.yml
146: image: reg.timinglee.org/flannel/flannel:v0.25.5
173: image: reg.timinglee.org/flannel/flannel-cni-plugin:v1.5.1-flannel1
184: image: reg.timinglee.org/flannel/flannel:v0.25.5
#安装flannel网络插件
[root@k8s-master ~]# kubectl apply -f kube-flannel.yml2.2.2.8 节点扩容
确认启动服务kubelet.service和cri-docker.service
[root@k8s-master ~]# kubeadm token create --print-join-command
kubeadm join 172.25.254.100:6443 --token 5hwptm.zwn7epa6pvatbpwf --discovery-token-ca-cert-hash sha256:52f1a83b70ffc8744db5570288ab51987ef2b563bf906ba4244a300f61e9db23
[root@k8s-node1 & 2 ~]# kubeadm join 172.25.254.100:6443 --token 5hwptm.zwn7epa6pvatbpwf --discovery-token-ca-cert-hash sha256:52f1a83b70ffc8744db5570288ab51987ef2b563bf906ba4244a300f61e9db23 --cri-socket=unix:///var/run/cri-dockerd.sock
#在master阶段中查看所有node的状态
#所有阶段的STATUS为**Ready**状态，那么恭喜你，你的kubernetes就装好了！！
[root@k8s-master ~]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8s-master Ready control-plane 98m v1.30.0
k8s-node1 Ready <none> 21m v1.30.0
k8s-node2 Ready <none> 21m v1.30.0
#测试集群运行情况
#建立一个pod
[root@k8s-master ~]# kubectl run test --image nginx
#查看pod状态
[root@k8s-master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
test 1/1 Running 0 6m29s
#删除pod
root@k8s-master ~]# kubectl delete pod三、k8s中的资源管理
3.1介绍
在kubernetes中，所有的内容都抽象为资源，用户需要通过操作资源来管理kubernetes。
kubernetes的本质上就是一个集群系统，用户可以在集群中部署各种服务
所谓的部署服务，其实就是在kubernetes集群中运行一个个的容器，并将指定的程序跑在容器中。
kubernetes的最小管理单元是pod而不是容器，只能将容器放在
Pod中，kubernetes一般也不会直接管理Pod，而是通过
Pod控制器来管理Pod的。Pod中服务服务的访问是由kubernetes提供的
Service资源来实现。Pod中程序的数据需要持久化是由kubernetes提供的各种
存储系统来实现
3.2 资源管理方式
命令式对象管理：直接使用命令去操作kubernetes资源
kubectl run nginx-pod --image=nginx:latest --port=80命令式对象配置：通过命令配置和配置文件去操作kubernetes资源
kubectl create/patch -f nginx-pod.yaml声明式对象配置：通过apply命令和配置文件去操作kubernetes资源
kubectl apply -f nginx-pod.yaml
对比：
| 类型 | 适用环境 | 优点 | 缺点 |
| 命令式对象管理 | 测试 | 简单 | 只能操作活动对象，无法审计、跟踪 |
| 命令式对象配置 | 开发 | 可以审计、跟踪 | 项目大时，配置文件多，操作麻烦 |
| 声明式对象配置 | 开发 | 支持目录操作 | 意外情况下难以调试 |
3.2.1 命令式对象管理
kubectl是kubernetes集群的命令行工具，通过它能够对集群本身进行管理，并能够在集群上进行容器化应用的安装部署
# 查看所有pod
kubectl get pod# 查看某个pod
kubectl get pod pod_name# 查看某个pod,以yaml格式展示结果
kubectl get pod pod_name -o yaml
3.2.2 资源类型
kubernetes中所有的内容都抽象为资源
kubectl api-resources
常用资源类型
常见命令操作
3.2.3 基本命令示例
显示集群版本
[root@k8s-master ~]# kubectl version
Client Version: v1.30.0
Kustomize Version: v5.0.4-0.20230601165947-6ce0bf390ce3
Server Version: v1.30.0
显示集群信息
[root@k8s-master ~]# kubectl cluster-info
Kubernetes control plane is running at https://172.25.254.100:6443
To further debug and diagnose cluster problems, use 'kubectl cluster-info dump'.
创建一个webcluseter控制器，控制器中pod数量为2
[root@k8s-master ~]# kubectl create deployment webcluseter --image nginx --replicas 2
deployment.apps/webcluseter created
查看控制器
[root@k8s-master ~]# kubectl get deployments.apps
NAME READY UP-TO-DATE AVAILABLE AGE
webcluseter 2/2 2 2 42s
查看资源帮助
[root@k8s-master ~]# kubectl explain deployment
GROUP: apps
KIND: Deployment
VERSION: v1
DESCRIPTION:
Deployment enables declarative updates for Pods and ReplicaSets.
FIELDS:
apiVersion <string>
APIVersion defines the versioned schema of this representation of an object.
Servers should convert recognized schemas to the latest internal value, and
may reject unrecognized values. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources
kind <string>
Kind is a string value representing the REST resource this object
represents. Servers may infer this from the endpoint the client submits
requests to. Cannot be updated. In CamelCase. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds
metadata <ObjectMeta>
Standard object's metadata. More info:
https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata
spec <DeploymentSpec>
Specification of the desired behavior of the Deployment.
status <DeploymentStatus>
Most recently observed status of the Deployment.查看控制器参数帮助
[root@k8s-master ~]# kubectl explain deployment.spec
GROUP: apps
KIND: Deployment
VERSION: v1
FIELD: spec <DeploymentSpec>
DESCRIPTION:
Specification of the desired behavior of the Deployment.
DeploymentSpec is the specification of the desired behavior of the
Deployment.
FIELDS:
minReadySeconds <integer>
Minimum number of seconds for which a newly created pod should be ready
without any of its container crashing, for it to be considered available.
Defaults to 0 (pod will be considered available as soon as it is ready)
paused <boolean>
Indicates that the deployment is paused.
progressDeadlineSeconds <integer>
The maximum time in seconds for a deployment to make progress before it is
considered to be failed. The deployment controller will continue to process
failed deployments and a condition with a ProgressDeadlineExceeded reason
will be surfaced in the deployment status. Note that progress will not be
estimated during the time a deployment is paused. Defaults to 600s.
replicas <integer>
Number of desired pods. This is a pointer to distinguish between explicit
zero and not specified. Defaults to 1.
revisionHistoryLimit <integer>
The number of old ReplicaSets to retain to allow rollback. This is a pointer
to distinguish between explicit zero and not specified. Defaults to 10.
selector <LabelSelector> -required-
Label selector for pods. Existing ReplicaSets whose pods are selected by
this will be the ones affected by this deployment. It must match the pod
template's labels.
strategy <DeploymentStrategy>
The deployment strategy to use to replace existing pods with new ones.
template <PodTemplateSpec> -required-
Template describes the pods that will be created. The only allowed
template.spec.restartPolicy value is "Always".
编辑控制器配置
[root@k8s-master ~]# kubectl edit deployments.apps webcluseter
deployment.apps/webcluseter edited
[root@k8s-master ~]# kubectl get deployments.apps
NAME READY UP-TO-DATE AVAILABLE AGE
webcluseter 2/2 2 2 3m55s
利用补丁更改控制器配置
[root@k8s-master ~]# kubectl patch deployments.apps webcluseter -p '{"spec":{"replicas":4}}'
deployment.apps/webcluseter patched
[root@k8s-master ~]# kubectl get deployments.apps NAME READY UP-TO-DATE AVAILABLE AGE
webcluseter 4/4 4 4 6m51s
删除资源
[root@k8s-master ~]# kubectl delete deployments.apps webcluseter
deployment.apps "webcluseter" deleted
[root@k8s-master ~]# kubectl get deployments.apps
No resources found in default namespace.
3.2.4 运行和调试命令示例
运行一个pod
[root@k8s-master ~]# kubectl run testpod1 --image nginx
pod/testpod1 created
[root@k8s-master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
testpod1 1/1 Running 0 13s
端口暴露
[root@k8s-master ~]# kubectl get services
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 11h
[root@k8s-master ~]# kubectl expose pod testpod1 --port 80 --target-port 80
service/testpod1 exposed
[root@k8s-master ~]# kubectl get services
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 11h
testpod1 ClusterIP 10.105.223.44 <none> 80/TCP 4s
查看资源详细信息
[root@k8s-master ~]# kubectl describe pods testpod1
查看资源日志
[root@k8s-master ~]# kubectl logs pods/testpod1
交互运行pod
[root@k8s-master ~]# kubectl run -it testpod2 --image busybox
If you don't see a command prompt, try pressing enter.
/ #
/ # #ctrl+pq退出不停止pod
/ # Session ended, resume using 'kubectl attach testpod2 -c testpod2 -i -t' command when the pod is running
运行非交互pod
[root@k8s-master ~]# kubectl run nginx --image nginx
pod/nginx created
重新进入正向运行的容器，且容器有交互环境
[root@k8s-master ~]# kubectl attach pods/testpod2 -it
If you don't see a command prompt, try pressing enter.
/ #
/ #
在以及运行的pod中运行指定的命令
[root@k8s-master ~]# kubectl exec -it pods/nginx /bin/bash
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
root@nginx:/#
复制本地文件到pod中
[root@k8s-master ~]# kubectl cp anaconda-ks.cfg nginx:/
[root@k8s-master ~]# kubectl exec -it pods/nginx /bin/bash
kubectl exec [POD] [COMMAND] is DEPRECATED and will be removed in a future version. Use kubectl exec [POD] -- [COMMAND] instead.
root@nginx:/# ls
anaconda-ks.cfg dev etc lib64 opt run sys var
bin docker-entrypoint.d home media proc sbin tmp
boot docker-entrypoint.sh lib mnt root srv usr
root@nginx:/# exit
复制pod中的文件到本地
[root@k8s-master ~]# kubectl cp nginx:/lib64 jcl-nginxpod
3.2.3 高级命令示例
利用命令生成yaml模板文件
[root@k8s-master ~]# kubectl create deployment --image nginx web1 --dry-run=client -o yaml > web1.yml利用yaml文件生成资源
#编辑生成出来的资源模板
[root@k8s-master ~]# vim web1.yml
#启动yml文件
[root@k8s-master ~]# kubectl apply -f web1.yml
deployment.apps/web1 configured
#查看控制器资源
[root@k8s-master ~]# kubectl get deployments.apps
NAME READY UP-TO-DATE AVAILABLE AGE
web1 2/2 2 2 50s
#删除控制器
[root@k8s-master ~]# kubectl delete -f web1.yml
deployment.apps "web1" deleted[root@k8s-master ~]# kubectl run nginx --image nginx
pod/nginx created
管理资源标签
#查看资源标签
[root@k8s-master ~]# kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
nginx 1/1 Running 0 23s run=nginx
#设置标签
[root@k8s-master ~]# kubectl label pods nginx app=jcl
pod/nginx labeled
[root@k8s-master ~]# kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
nginx 1/1 Running 0 58s app=jcl,run=nginx
#更改标签
[root@k8s-master ~]# kubectl label pods nginx app=web --overwrite
pod/nginx labeled
[root@k8s-master ~]# kubectl get pods --show-labels
NAME READY STATUS RESTARTS AGE LABELS
nginx 1/1 Running 0 7m1s app=web,run=nginx
#删除标签
[root@k8s-master ~]# kubectl label pods nginx app-
pod/nginx unlabeled
[root@k8s-master ~]# kubectl get pods nginx --show-labels
NAME READY STATUS RESTARTS AGE LABELS
nginx 1/1 Running 0 9m11s run=nginx
标签是控制器识别pod的标识
[root@k8s-master ~]# kubectl label pods web1-787d8ccbdc-rwxfh app=jcl --overwrite
pod/web1-787d8ccbdc-rwxfh labeled
#监控标签变化会发现当我们把标签改成jcl后，控制器会自动再开一个标签为web1的标签
[root@k8s-master ~]# watch kubectl get pods --show-labels
Every 2.0s: kubectl get pods --show-labels k8s-master: Tue Sep 3 13:29:07 2024
NAME READY STATUS RESTARTS AGE LABELS
nginx 1/1 Running 0 69m run=nginx
web1-787d8ccbdc-jfmzx 1/1 Running 0 36s app=web1,pod-template-has
h=787d8ccbdc
web1-787d8ccbdc-rwxfh 1/1 Running 0 109s app=jcl,pod-template-hash
=787d8ccbdc
web1-787d8ccbdc-wcczl 1/1 Running 0 109s app=web1,pod-template-has
h=787d8ccbdc
四、Pod管理
什么是pod：
-
Pod是可以创建和管理Kubernetes计算的最小可部署单元
-
一个Pod代表着集群中运行的一个进程，每个pod都有一个唯一的ip。
-
一个pod类似一个豌豆荚，包含一个或多个容器（通常是docker）
-
多个容器间共享IPC、Network和UTC namespace。
4.1 创建自主式pod （生产不推荐）
[root@k8s-master ~]# kubectl run strongjcl --image nginx
pod/strongjcl created
[root@k8s-master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
strongjcl 1/1 Running 0 11s
[root@k8s-master ~]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
strongjcl 1/1 Running 0 32s 10.244.1.11 k8s-node1 <none> <none>
4.2 利用控制器管理pod（推荐）
[root@k8s-master ~]# kubectl create deployment jcl --image nginx
deployment.apps/jcl created
[root@k8s-master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
jcl-765d6665c9-hqvws 1/1 Running 0 12s
#利用控制给pod扩容
[root@k8s-master ~]# kubectl scale deployment jcl --replicas 6
deployment.apps/jcl scaled
[root@k8s-master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
jcl-765d6665c9-9klwr 1/1 Running 0 11s
jcl-765d6665c9-bnn6b 1/1 Running 0 11s
jcl-765d6665c9-chkjz 1/1 Running 0 11s
jcl-765d6665c9-hqvws 1/1 Running 0 54s
jcl-765d6665c9-sv2dw 1/1 Running 0 11s
jcl-765d6665c9-v9zvm 1/1 Running 0 11s
#缩容
[root@k8s-master ~]# kubectl scale deployment jcl --replicas 2
deployment.apps/jcl scaled
[root@k8s-master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
jcl-765d6665c9-9klwr 1/1 Running 0 34s
jcl-765d6665c9-hqvws 1/1 Running 0 77s
4.3 应用版本的更新
#利用控制器建立pod
[root@k8s-master ~]# kubectl create deployment jcl --image myapp:v1 --replicas 2
deployment.apps/jcl created
#暴漏端口
[root@k8s-master ~]# kubectl expose deployment jcl --port 80 --target-port 80
service/jcl exposed
[root@k8s-master ~]# kubectl get services
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 2d17h
jcl ClusterIP 10.110.195.120 <none> 80/TCP 8s
#访问服务
[root@k8s-master ~]# curl 10.110.195.120
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>
[root@k8s-master ~]# curl 10.110.195.120
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>
[root@k8s-master ~]# curl 10.110.195.120
#产看历史版本
[root@k8s-master ~]# kubectl rollout history deployment jcl
deployment.apps/jcl
REVISION CHANGE-CAUSE
1 <none>
#更新控制器镜像版本
[root@k8s-master ~]# kubectl set image deployments/jcl myapp=myapp:v2
deployment.apps/jcl image updated
#查看历史版本
[root@k8s-master ~]# kubectl rollout history deployment jcl
deployment.apps/jcl
REVISION CHANGE-CAUSE
1 <none>
2 <none>
#访问内容测试
[root@k8s-master ~]# curl 10.110.195.120
Hello MyApp | Version: v2 | <a href="hostname.html">Pod Name</a>
[root@k8s-master ~]# curl 10.110.195.120
#版本回滚
[root@k8s-master ~]# kubectl rollout undo deployment jcl --to-revision 1
deployment.apps/jcl rolled back
[root@k8s-master ~]# curl 10.110.195.120
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>4.4 利用yaml文件部署应用
4.4.1 用yaml文件部署应用的优点
声明式配置：
清晰表达期望状态：以声明式的方式描述应用的部署需求，包括副本数量、容器配置、网络设置等。这使得配置易于理解和维护，并且可以方便地查看应用的预期状态。
可重复性和版本控制：配置文件可以被版本控制，确保在不同环境中的部署一致性。可以轻松回滚到以前的版本或在不同环境中重复使用相同的配置。
团队协作：便于团队成员之间共享和协作，大家可以对配置文件进行审查和修改，提高部署的可靠性和稳定性。
灵活性和可扩展性：
丰富的配置选项：可以通过 YAML 文件详细地配置各种 Kubernetes 资源，如 Deployment、Service、ConfigMap、Secret 等。可以根据应用的特定需求进行高度定制化。
组合和扩展：可以将多个资源的配置组合在一个或多个 YAML 文件中，实现复杂的应用部署架构。同时，可以轻松地添加新的资源或修改现有资源以满足不断变化的需求。
与工具集成：
与 CI/CD 流程集成：可以将 YAML 配置文件与持续集成和持续部署（CI/CD）工具集成，实现自动化的应用部署。例如，可以在代码提交后自动触发部署流程，使用配置文件来部署应用到不同的环境。
命令行工具支持：Kubernetes 的命令行工具
kubectl对 YAML 配置文件有很好的支持，可以方便地应用、更新和删除配置。同时，还可以使用其他工具来验证和分析 YAML 配置文件，确保其正确性和安全性。
4.4.2 资源清单参数
| 参数名称 | 类型 | 参数说明 |
|---|---|---|
| version | String | 这里是指的是K8S API的版本，目前基本上是v1，可以用kubectl api-versions命令查询 |
| kind | String | 这里指的是yaml文件定义的资源类型和角色，比如:Pod |
| metadata | Object | 元数据对象，固定值就写metadata |
| metadata.name | String | 元数据对象的名字，这里由我们编写，比如命名Pod的名字 |
| metadata.namespace | String | 元数据对象的命名空间，由我们自身定义 |
| Spec | Object | 详细定义对象，固定值就写Spec |
| spec.containers[] | list | 这里是Spec对象的容器列表定义，是个列表 |
| spec.containers[].name | String | 这里定义容器的名字 |
| spec.containers[].image | string | 这里定义要用到的镜像名称 |
| spec.containers[].imagePullPolicy | String | 定义镜像拉取策略，有三个值可选： (1) Always: 每次都尝试重新拉取镜像 (2) IfNotPresent:如果本地有镜像就使用本地镜像 (3) )Never:表示仅使用本地镜像 |
| spec.containers[].command[] | list | 指定容器运行时启动的命令，若未指定则运行容器打包时指定的命令 |
| spec.containers[].args[] | list | 指定容器运行参数，可以指定多个 |
| spec.containers[].workingDir | String | 指定容器工作目录 |
| spec.containers[].volumeMounts[] | list | 指定容器内部的存储卷配置 |
| spec.containers[].volumeMounts[].name | String | 指定可以被容器挂载的存储卷的名称 |
| spec.containers[].volumeMounts[].mountPath | String | 指定可以被容器挂载的存储卷的路径 |
| spec.containers[].volumeMounts[].readOnly | String | 设置存储卷路径的读写模式，ture或false，默认为读写模式 |
| spec.containers[].ports[] | list | 指定容器需要用到的端口列表 |
| spec.containers[].ports[].name | String | 指定端口名称 |
| spec.containers[].ports[].containerPort | String | 指定容器需要监听的端口号 |
| spec.containers[] ports[].hostPort | String | 指定容器所在主机需要监听的端口号，默认跟上面containerPort相同，注意设置了hostPort同一台主机无法启动该容器的相同副本(因为主机的端口号不能相同，这样会冲突) |
| spec.containers[].ports[].protocol | String | 指定端口协议，支持TCP和UDP，默认值为 TCP |
| spec.containers[].env[] | list | 指定容器运行前需设置的环境变量列表 |
| spec.containers[].env[].name | String | 指定环境变量名称 |
| spec.containers[].env[].value | String | 指定环境变量值 |
| spec.containers[].resources | Object | 指定资源限制和资源请求的值(这里开始就是设置容器的资源上限) |
| spec.containers[].resources.limits | Object | 指定设置容器运行时资源的运行上限 |
| spec.containers[].resources.limits.cpu | String | 指定CPU的限制，单位为核心数，1=1000m |
| spec.containers[].resources.limits.memory | String | 指定MEM内存的限制，单位为MIB、GiB |
| spec.containers[].resources.requests | Object | 指定容器启动和调度时的限制设置 |
| spec.containers[].resources.requests.cpu | String | CPU请求，单位为core数，容器启动时初始化可用数量 |
| spec.containers[].resources.requests.memory | String | 内存请求，单位为MIB、GIB，容器启动的初始化可用数量 |
| spec.restartPolicy | string | 定义Pod的重启策略，默认值为Always. (1)Always: Pod-旦终止运行，无论容器是如何 终止的，kubelet服务都将重启它 (2)OnFailure: 只有Pod以非零退出码终止时，kubelet才会重启该容器。如果容器正常结束(退出码为0)，则kubelet将不会重启它 (3) Never: Pod终止后，kubelet将退出码报告给Master，不会重启该 |
| spec.nodeSelector | Object | 定义Node的Label过滤标签，以key:value格式指定 |
| spec.imagePullSecrets | Object | 定义pull镜像时使用secret名称，以name:secretkey格式指定 |
| spec.hostNetwork | Boolean | 定义是否使用主机网络模式，默认值为false。设置true表示使用宿主机网络，不使用docker网桥，同时设置了true将无法在同一台宿主机 上启动第二个副本 |
4.4.3 如何获得资源帮助
kubectl explain pod.spec.containers4.4.4 编写示例
4.4.4.1 示例1：运行简单的单个容器pod
#用命令获取yaml模板
[root@k8s-master ~]# kubectl run timinglee --image myapp:v1 --dry-run=client -o yaml > pod.yml
[root@k8s-master ~]# vim pod.yml
apiVersion: v1
kind: Pod
#以下为pod的参数设置
metadata:
labels:
run: timing #pod标签
name: timinglee #pod名称
#以下为pod的期望值
spec:
containers:
- image: myapp:v1 #pod镜像
name: timinglee #容器名称4.4.4.2 示例2：运行多个容器pod
注意如果多个容器运行在一个pod中，资源共享的同时在使用相同资源时也会干扰，比如端口
#一个端口干扰示例：
[root@k8s-master ~]# vim pod.yml
apiVersion: v1
kind: Pod
metadata:
labels:
run: jcl
name: jcl
spec:
containers:
- image: nginx:latest
name: web1
- image: nginx:latest
name: web2
[root@k8s-master ~]# kubectl apply -f pod.yml
pod/jclcreated
[root@k8s-master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
jcl 1/2 Error 1 (14s ago) 18s
#查看日志
[root@k8s-master ~]# kubectl logs jcl web2
2024/08/31 12:43:20 [emerg] 1#1: bind() to [::]:80 failed (98: Address already in use)
nginx: [emerg] bind() to [::]:80 failed (98: Address already in use)
2024/08/31 12:43:20 [notice] 1#1: try again to bind() after 500ms
2024/08/31 12:43:20 [emerg] 1#1: still could not bind()
nginx: [emerg] still could not bind()在一个pod中开启多个容器时一定要确保容器彼此不能互相干扰
[root@k8s-master ~]# vim pod.yml
[root@k8s-master ~]# kubectl apply -f pod.yml
pod/timinglee created
apiVersion: v1
kind: Pod
metadata:
labels:
run: [root@k8s-master ~]# vim pod.yml
[root@k8s-master ~]# kubectl apply -f pod.yml
pod/timinglee created
apiVersion: v1
kind: Pod
metadata:
labels:
run: jcl
name: jcl
spec:
containers:
- image: nginx:latest
name: web1
- image: busybox:latest
name: busybox
command: ["/bin/sh","-c","sleep 1000000"]
[root@k8s-master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
jcl 2/2 Running 0 19s
name: jcl
spec:
containers:
- image: nginx:latest
name: web1
- image: busybox:latest
name: busybox
command: ["/bin/sh","-c","sleep 1000000"]
[root@k8s-master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
jcl 2/2 Running 0 19s4.4.4.3 示例3：理解pod间的网络整合
同在一个pod中的容器共用一个网络站，类似于docker的joind网络
[root@k8s-master ~]# vim pod.yml
apiVersion: v1
kind: Pod
metadata:
labels:
run: jcl
name: test
spec:
containers:
- image: myapp:v1
name: myapp1
- image: busyboxplus:latest
name: busyboxplus
command: ["/bin/sh","-c","sleep 1000000"]
[root@k8s-master ~]# kubectl apply -f pod.yml
pod/test created
[root@k8s-master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
test 2/2 Running 0 8s
[root@k8s-master ~]# kubectl exec test -c busyboxplus -- curl -s localhost
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>
4.4.4.4 示例4：端口映射
[root@k8s-master ~]# vim pod.yml
apiVersion: v1
kind: Pod
metadata:
labels:
run: jcl
name: test
spec:
containers:
- image: myapp:v1
name: myapp1
ports:
- name: http
containerPort: 80
hostPort: 80
protocol: TCP
#测试
[root@k8s-master ~]# kubectl apply -f pod.yml
pod/test created
[root@k8s-master ~]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
test 1/1 Running 0 12s 10.244.1.2 k8s-node1 <none> <none>
[root@k8s-master ~]# curl k8s-node1
Hello MyApp | Version: v1 | <a href="hostname.html">Pod Name</a>4.4.4.5 示例5：如何设定环境变量
[root@k8s-master ~]# vim pod.yml
apiVersion: v1
kind: Pod
metadata:
labels:
run: jcl
name: test
spec:
containers:
- image: busybox:latest
name: busybox
command: ["/bin/sh","-c","echo $NAME;sleep 3000000"]
env:
- name: NAME
value: jcl
[root@k8s-master ~]# kubectl apply -f pod.yml
pod/test created
[root@k8s-master ~]# kubectl logs pods/test busybox
jcl4.4.4.6 示例6：资源限制
资源限制会影响pod的Qos Class资源优先级，资源优先级分为Guaranteed > Burstable > BestEffort
[root@k8s-master ~]# vim pod.yml
apiVersion: v1
kind: Pod
metadata:
labels:
run: jcl
name: test
spec:
containers:
- image: myapp:v1
name: myapp
resources:
limits: #pod使用资源的最高限制
cpu: 500m
memory: 100M
requests: #pod期望使用资源量，不能大于limits
cpu: 500m
memory: 100M
root@k8s-master ~]# kubectl apply -f pod.yml
pod/test created
[root@k8s-master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
test 1/1 Running 0 3s
[root@k8s-master ~]# kubectl describe pods test
Limits:
cpu: 500m
memory: 100M
Requests:
cpu: 500m
memory: 100M
QoS Class: Guaranteed4.4.4.7 示例7 容器启动管理
[root@k8s-master ~]# vim pod.yml
apiVersion: v1
kind: Pod
metadata:
labels:
run: jcl
name: test
spec:
restartPolicy: Always
containers:
- image: myapp:v1
name: myapp
[root@k8s-master ~]# kubectl apply -f pod.yml
pod/test created
[root@k8s-master ~]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
test 1/1 Running 0 6s 10.244.2.3 k8s-node2 <none> <none>
[root@k8s-node2 ~]# docker rm -f ccac1d64ea814.4.4.8 示例8 选择运行节点
[root@k8s-master ~]# vim pod.yml
apiVersion: v1
kind: Pod
metadata:
labels:
run: jcl
name: test
spec:
nodeSelector:
kubernetes.io/hostname: k8s-node1
restartPolicy: Always
containers:
- image: myapp:v1
name: myapp
[root@k8s-master ~]# kubectl apply -f pod.yml
pod/test created
[root@k8s-master ~]# kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
test 1/1 Running 0 21s 10.244.1.5 k8s-node1 <none> <none>4.4.4.9 示例9 共享宿主机网络
[root@k8s-master ~]# vim pod.yml
apiVersion: v1
kind: Pod
metadata:
labels:
run: jcl
name: test
spec:
hostNetwork: true
restartPolicy: Always
containers:
- image: busybox:latest
name: busybox
command: ["/bin/sh","-c","sleep 100000"]
[root@k8s-master ~]# kubectl apply -f pod.yml
pod/test created
[root@k8s-master ~]# kubectl exec -it pods/test -c busybox -- /bin/sh
/ # ifconfig
cni0 Link encap:Ethernet HWaddr E6:D4:AA:81:12:B4
inet addr:10.244.2.1 Bcast:10.244.2.255 Mask:255.255.255.0
inet6 addr: fe80::e4d4:aaff:fe81:12b4/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1450 Metric:1
RX packets:6259 errors:0 dropped:0 overruns:0 frame:0
TX packets:6495 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:506704 (494.8 KiB) TX bytes:625439 (610.7 KiB)
docker0 Link encap:Ethernet HWaddr 02:42:99:4A:30:DC
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)
eth0 Link encap:Ethernet HWaddr 00:0C:29:6A:A8:61
inet addr:172.25.254.20 Bcast:172.25.254.255 Mask:255.255.255.0
inet6 addr: fe80::8ff3:f39c:dc0c:1f0e/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:27858 errors:0 dropped:0 overruns:0 frame:0
TX packets:14454 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:26591259 (25.3 MiB) TX bytes:1756895 (1.6 MiB)
flannel.1 Link encap:Ethernet HWaddr EA:36:60:20:12:05
inet addr:10.244.2.0 Bcast:0.0.0.0 Mask:255.255.255.255
inet6 addr: fe80::e836:60ff:fe20:1205/64 Scope:Link
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:40 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:163 errors:0 dropped:0 overruns:0 frame:0
TX packets:163 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:13630 (13.3 KiB) TX bytes:13630 (13.3 KiB)
veth9a516531 Link encap:Ethernet HWaddr 7A:92:08:90:DE:B2
inet6 addr: fe80::7892:8ff:fe90:deb2/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1450 Metric:1
RX packets:6236 errors:0 dropped:0 overruns:0 frame:0
TX packets:6476 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:592532 (578.6 KiB) TX bytes:622765 (608.1 KiB)
/ # exit五、pod的生命周期
5.1INIT容器
官方文档：Pod | Kubernetes
-
Pod 可以包含多个容器，应用运行在这些容器里面，同时 Pod 也可以有一个或多个先于应用容器启动的 Init 容器。
-
Init 容器与普通的容器非常像，除了如下两点：
-
它们总是运行到完成
-
init 容器不支持 Readiness，因为它们必须在 Pod 就绪之前运行完成，每个 Init 容器必须运行成功，下一个才能够运行。
-
-
如果Pod的 Init 容器失败，Kubernetes 会不断地重启该 Pod，直到 Init 容器成功为止。但是，如果 Pod 对应的 restartPolicy 值为 Never，它不会重新启动。
5.1.1 INIT 容器的功能
-
Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。
-
Init 容器可以安全地运行这些工具，避免这些工具导致应用镜像的安全性降低。
-
应用镜像的创建者和部署者可以各自独立工作，而没有必要联合构建一个单独的应用镜像。
-
Init 容器能以不同于Pod内应用容器的文件系统视图运行。因此，Init容器可具有访问 Secrets 的权限，而应用容器不能够访问。
-
由于 Init 容器必须在应用容器启动之前运行完成，因此 Init 容器提供了一种机制来阻塞或延迟应用容器的启动，直到满足了一组先决条件。一旦前置条件满足，Pod内的所有的应用容器会并行启动。
5.1.2 INIT 容器示例
[root@k8s-master ~]# vim pod.yml
apiVersion: v1
kind: Pod
metadata:
labels:
name: initpod
name: initpod
spec:
containers:
- image: myapp:v1
name: myapp
initContainers:
- name: init-myservice
image: busybox
command: ["sh","-c","until test -e /testfile;do echo wating for myservice; sleep 2;done"]
[root@k8s-master ~]# kubectl apply -f pod.yml
pod/initpod created
[root@k8s-master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
initpod 0/1 Init:0/1 0 3s
[root@k8s-master ~]# kubectl logs pods/initpod init-myservice
wating for myservice
wating for myservice
wating for myservice
wating for myservice
wating for myservice
wating for myservice
[root@k8s-master ~]# kubectl exec pods/initpod -c init-myservice -- /bin/sh -c "touch /testfile"
[root@k8s-master ~]# kubectl get pods NAME READY STATUS RESTARTS AGE
initpod 1/1 Running 0 62s5.2 探针
探针是由 kubelet 对容器执行的定期诊断:
-
ExecAction：在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
-
TCPSocketAction：对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开，则诊断被认为是成功的。
-
HTTPGetAction：对指定的端口和路径上的容器的 IP 地址执行 HTTP Get 请求。如果响应的状态码大于等于200 且小于 400，则诊断被认为是成功的。
每次探测都将获得以下三种结果之一：
-
成功：容器通过了诊断。
-
失败：容器未通过诊断。
-
未知：诊断失败，因此不会采取任何行动。
Kubelet 可以选择是否执行在容器上运行的三种探针执行和做出反应：
-
livenessProbe：指示容器是否正在运行。如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其 重启策略 的影响。如果容器不提供存活探针，则默认状态为 Success。
-
readinessProbe：指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的 IP 地址。初始延迟之前的就绪状态默认为 Failure。如果容器不提供就绪探针，则默认状态为 Success。
-
startupProbe: 指示容器中的应用是否已经启动。如果提供了启动探测(startup probe)，则禁用所有其他探测，直到它成功为止。如果启动探测失败，kubelet 将杀死容器，容器服从其重启策略进行重启。如果容器没有提供启动探测，则默认状态为成功Success。
ReadinessProbe 与 LivenessProbe 的区别
-
ReadinessProbe 当检测失败后，将 Pod 的 IP:Port 从对应的 EndPoint 列表中删除。
-
LivenessProbe 当检测失败后，将杀死容器并根据 Pod 的重启策略来决定作出对应的措施
StartupProbe 与 ReadinessProbe、LivenessProbe 的区别
-
如果三个探针同时存在，先执行 StartupProbe 探针，其他两个探针将会被暂时禁用，直到 pod 满足 StartupProbe 探针配置的条件，其他 2 个探针启动，如果不满足按照规则重启容器。
-
另外两种探针在容器启动后，会按照配置，直到容器消亡才停止探测，而 StartupProbe 探针只是在容器启动后按照配置满足一次后，不在进行后续的探测。
5.2.1 探针实例
5.2.1.1 存活探针示例：
[root@k8s-master ~]# vim pod.yml
apiVersion: v1
kind: Pod
metadata:
labels:
name: liveness
name: liveness
spec:
containers:
- image: myapp:v1
name: myapp
livenessProbe:
tcpSocket: #检测端口存在性
port: 8080
initalDelaySeconds: 3 #容器启动后要等待多少秒后就探针开始工作，默认是 0
periodSeconds: 1 #执行探测的时间间隔，默认为 10s
timeoutSeconds: 1 #探针执行检测请求后，等待响应的超时时间，默认为 1s
#测试：
[root@k8s-master ~]# kubectl apply -f pod.yml
pod/liveness created
[root@k8s-master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
liveness 0/1 CrashLoopBackOff 2 (7s ago) 22s
[root@k8s-master ~]# kubectl describe pods
Warning Unhealthy 1s (x9 over 13s) kubelet Liveness probe failed: dial tcp 10.244.2.6:8080: connect: connection refused5.2.1.2 就绪探针示例：
[root@k8s-master ~]# vim pod.yml
apiVersion: v1
kind: Pod
metadata:
labels:
name: readiness
name: readiness
spec:
containers:
- image: myapp:v1
name: myapp
readinessProbe:
httpGet:
path: /test.html
port: 80
initialDelaySeconds: 1
periodSeconds: 3
timeoutSeconds: 1
#测试：
[root@k8s-master ~]# kubectl expose pod readiness --port 80 --target-port 80
[root@k8s-master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
readiness 0/1 Running 0 5m25s
[root@k8s-master ~]# kubectl describe pods readiness
Warning Unhealthy 26s (x66 over 5m43s) kubelet Readiness probe failed: HTTP probe failed with statuscode: 404
[root@k8s-master ~]# kubectl describe services readiness
Name: readiness
Namespace: default
Labels: name=readiness
Annotations: <none>
Selector: name=readiness
Type: ClusterIP
IP Family Policy: SingleStack
IP Families: IPv4
IP: 10.100.171.244
IPs: 10.100.171.244
Port: <unset> 80/TCP
TargetPort: 80/TCP
Endpoints: #没有暴漏端口，就绪探针探测不满足暴漏条件
Session Affinity: None
Events: <none>
kubectl exec pods/readiness -c myapp -- /bin/sh -c "echo test > /usr/share/nginx/html/test.html"
[root@k8s-master ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
readiness 1/1 Running 0 7m49s
[root@k8s-master ~]# kubectl describe services readiness
Name: readiness
Namespace: default
Labels: name=readiness
Annotations: <none>
Selector: name=readiness
Type: ClusterIP
IP Family Policy: SingleStack
IP Families: IPv4
IP: 10.100.171.244
IPs: 10.100.171.244
Port: <unset> 80/TCP
TargetPort: 80/TCP
Endpoints: 10.244.2.8:80 #满组条件端口暴漏
Session Affinity: None
Events: <none>
标签：实战,kubectl,kubernetes,容器,master,pod,k8s,root From： https://blog.csdn.net/strongjcl/article/details/141888921