Master ：任务分配调度端 Master可以有多个端 (高可用建筑Master节点必须大于1奇数 如3.5.7等）当Master三个节点允许一个节点死亡 五个节点允许死亡

node：可以有任何真实节点

Kubelet：通过维护容器的生命周期O-CRI实现接口调用k8s 与容器层对接也负责 Volume（CSI）和网络（CNI）的管理

Kube-proxy ：负责为 Service 提供 cluster 内部服务发现与负载平衡 通过调用net links接口实现iptables ipvs的规则创建

etcd ： 可靠的分布式键值存储服务 分布式集群存储关键数据 协助分布式集群的正常运行

Raft ： 共识算法 每一个Raft集群包含多个服务器的任何时刻 每个服务器都可能在 leder、 follower 和candidate状态 正常情况下，一个集群只有一个leder 其他服务器都是 follower状态

etcd的接口版本 v2 将数据写入内存 v3 将数据写入本地文件系统 实现数据的持久性 但并发量较低

Kubernetes API Server ：作为 Kubernetes 该系统的入口包装了核心对象的添加、删除和检查操作 RESTful API 接口方式提供给外部客户和内部组件调用。维护的 REST 对象持久到 Etcd 中存储

Kubernetes Scheduler：新建立的 Pod 进行节点 (node) 负责集群资源调度的选择(即分配机器)。组件可以很容易地被其他调度器取代

Controller Manager ：负责维护故障检测、自动扩展、滚动更新等集群状态

Container runtime ：负责镜像管理以及 Pod 以及容器的真实运行（CRI）

Core DNS ：集群内域名和地址的分析关系

Ingress controller ：为k8s服务提供外网入口 ，给k8s集群提供一个七层负载

Prometheus ：为整个集群提供资源监控能力

Dashboard ：提供 B/S 访问系统允许用户通过 web 集群管理和设置

Federation ：提供不同数据中心的跨可用区集群 K8S 集群管理能力

Pod ： k8s最小调度单位

pause ：谷歌创作的非常精简的镜像大小只有几个MB 它是Pod第一个启动容器 启动后，实现两个功能1的初始化网络战，2挂载存储卷

main-C ：每一个Pod至少有一个main-c容器 也可以有多个

#Pod创建 docker run --name x1 -d pause               #启动pause docker run --name x2 --volumes-from x1 --network container:x1   #启动mainc --volumes-from x1 持久化数据 --network container:x1 共享网络  

自主式Pod ：优点创造简单，缺点不稳定

控制器管理Pod ：

ReplicationController 用于确保容器应用的副本数始终保持在用户定义的副本数中，即如果容器异常退出，将自动创建新的副本数 Pod 替换；如果容器异常多，也会自动回收。在新版本的 Kubernetes 中建议使用 ReplicaSet 来取代 ReplicationControlle 简写为RC

Kubernetes 假设所有的网络模型都假设了 Pod 它们都在平坦的网络空间中，可以直接连接，这是在 GCE（Google Compute Engine）它是现成的网络模型，Kubernetes 假定这个网络已经存在。建在私有云中 Kubernetes 集群不能假设网络已经存在。我们需要在不同的节点上实现这个网络假设 Docker 先打开容器之间的相互访问，然后运行 Kubernetes

Flannel 是 CoreOS 团队针对 Kubernetes 网络规划服务的设计，简单地说，它的功能是由集群中的不同节点主机创建的 Docker 集群中唯一的虚拟容器IP地址。而且它也可以在这里 IP 在地址之间建立覆盖网络（Overlay Network），通过这个覆盖网络，将数据包原封不动地传输到目标容器中

Flannel网络原理

地址规划服务 ： 通过flanneld 向etcd 申请网段 所以每个节点的网段都不一致，所以pod 唯一的全集群地址 此时ETCD物理网卡信息将记录网络端和相应节点

覆盖型网络 ：数据报纸的二次包装(采用UDP协议）

同一个pod不同容器之间 基于回环接口通信 （lo）

不同pod之间通讯： 同物理机： 基于docker0 不同物理机 ：flannel的二次封装

扩展：软路由的安装和配置

创建新的虚拟机 选择其他系统，其他系统 内存1G 内核1核 两张个网卡 一个仅主机 一个NAT 首先只配置主机网卡

安装完成后 配置IP 访问浏览器 进行设置

kubernetes 基于golang编写

二进制方案运行

操作容器化方案：kubeadm

hostnamectl  set-hostname   k8s-master01

yum install -y conntrack ntpdate ntp ipvsadm ipset  iptables curl sysstat libseccomp wget  vim net-tools git

systemctl  stop firewalld  &&  systemctl  disable firewalld
yum -y install iptables-services  &&  systemctl  start iptables  &&  systemctl  enable iptables  &&  iptables -F  &&  service iptables save

swapoff -a && sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab        #关闭交换分区
setenforce 0 && sed -i 's/^SELINUX=.*/SELINUX=disabled/' /etc/selinux/config

cat > kubernetes.conf <<EOF
net.bridge.bridge-nf-call-iptables=1
net.bridge.bridge-nf-call-ip6tables=1
net.ipv4.ip_forward=1
net.ipv4.tcp_tw_recycle=0
vm.swappiness=0 # 禁止使用 swap 空间，只有当系统 OOM 时才允许使用它
vm.overcommit_memory=1 # 不检查物理内存是否够用
vm.panic_on_oom=0 # 开启 OOM	
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=1
net.netfilter.nf_conntrack_max=2310720
EOF
cp kubernetes.conf  /etc/sysctl.d/kubernetes.conf
sysctl -p /etc/sysctl.d/kubernetes.conf

# 设置系统时区为 中国/上海
timedatectl set-timezone Asia/Shanghai
# 将当前的 UTC 时间写入硬件时钟
timedatectl set-local-rtc 0
# 重启依赖于系统时间的服务
systemctl restart rsyslog 
systemctl restart crond

#master节点
vim /etc/chrony.conf         #修改配置文件 如果没有这个配置文件则需要安装 yum -y install chrony
server ntp1.aliyun.com iburst
server ntp2.aliyun.com iburst
server ntp3.aliyun.com iburst #将原本的注释掉改为阿里云的时间同步服务器

# Allow NTP client access from local network.
allow 192.168.88.0/24                                             #修改允许同步的网段
# Serve time even if not synchronized to a time source.
local stratum 10                                                 #取消此选项注释 给予权重
 
#保存退出后执行
systemctl restart chronyd
systemctl enable chronyd


node节点
vim /etc/chronyconf
#指定时间同步服务器为master节点
#保存退出后执行
systemctl restart chronyd
systemctl enable chronyd

 systemctl stop postfix && systemctl disable postfix

mkdir /var/log/journal # 持久化保存日志的目录
mkdir /etc/systemd/journald.conf.d
    cat > /etc/systemd/journald.conf.d/99-prophet.conf <<EOF
  [Journal]
  # 持久化保存到磁盘
  Storage=persistent

  # 压缩历史日志
  Compress=yes

  SyncIntervalSec=5m
  RateLimitInterval=30s
  RateLimitBurst=1000

  # 最大占用空间 10G
  SystemMaxUse=10G

  # 单日志文件最大 200M
  SystemMaxFileSize=200M

  # 日志保存时间 2 周
  MaxRetentionSec=2week

  # 不将日志转发到 syslog
  ForwardToSyslog=no
  EOF
 systemctl restart systemd-journald

CentOS 7.x 系统自带的 3.10.x 内核存在一些 Bugs，导致运行的 Docker、Kubernetes 不稳定，例如： rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-3.el7.elrepo.noarch.rpm

rpm -Uvh http://www.elrepo.org/elrepo-release-7.0-3.el7.elrepo.noarch.rpm
# 安装完成后检查 /boot/grub2/grub.cfg 中对应内核 menuentry 中是否包含 initrd16 配置，如果没有，再安装一次！
yum --enablerepo=elrepo-kernel install -y kernel-lt
# 设置开机从新内核启动
grub2-set-default 'CentOS Linux (4.4.189-1.el7.elrepo.x86_64) 7 (Core)'
reboot                                  #重载
uname -r                                查看当前内核版本

modprobe br_netfilter

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 #在5.4内核中 这条参数中_ipv4被去掉了 EOF

chmod 755 /etc/sysconfig/modules/ipvs.modules && bash /etc/sysconfig/modules/ipvs.modules && lsmod | grep -e ip_vs -e nf_conntrack_ipv4

yum install -y yum-utils device-mapper-persistent-data lvm2

yum-config-manager \
  --add-repo \
  http://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo
 
yum install -y docker-ce

## 创建 /etc/docker 目录 
mkdir /etc/docker

# 配置 daemon.
cat > /etc/docker/daemon.json <<EOF { "exec-opts": ["native.cgroupdriver=systemd"], "log-driver": "json-file", "log-opts": { "max-size": "100m" }, "insecure-registries": ["hub.hongfu.com"] } EOF
mkdir -p /etc/systemd/system/docker.service.d

# 重启docker服务
systemctl daemon-reload && systemctl restart docker && systemctl enable docker

cat <<EOF > /etc/yum.repos.d/kubernetes.repo [kubernetes] name=Kubernetes baseurl=http://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64 enabled=1 gpgcheck=0 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
#配置阿里云的源
yum -y  install  kubeadm-1.15.1 kubectl-1.15.1 kubelet-1.15.1       #kubectl-1.15.1在node节点可以不装
systemctl enable kubelet.service                              

  kubeadm config print init-defaults > kubeadm-config.yaml
	localAPIEndpoint:
        advertiseAddress: 192.168.66.10
    kubernetesVersion: v1.15.1
	networking:
      podSubnet: "10.244.0.0/16"
      serviceSubnet: 10.96.0.0/12
    ---
    apiVersion: kubeproxy.config.k8s.io/v1alpha1
    kind: KubeProxyConfiguration
    featureGates:
      SupportIPVSProxyMode: true
    mode: ipvs

kubeadm init --config=kubeadm-config.yaml --experimental-upload-certs | tee kubeadm-init.log

执行安装日志中的加入命令即可

kubenretes-master执行以下命令

mkdir -p /usr/local/kubenretes/install                               #创建目录用以保存文件
mv kubeadm-config.yeml kubeadm-init.log /usr/local/kubenretes/install #将初始化配置文件保存到该目录下方便查看
mkdir /usr/local/kubenretes/cni                                        #保存网络插件的目录
mv /root/flannel/*  /usr/local/kubenretes/cni

安装网络插件 flannel

#导入网络插件
tar -zcvf flannel.tar.gz
docker load -i flannel.tar                                            #导入镜像
#将flannel镜像传给n1节点和n2节点的root目录下
docker load -i flannel.tar                                            #n1和n2同样导入镜像
kubectl create -f kube-flannel.yeml                                   #创建资源 -f指定文件 
kubectl delete deployment nginx                                       #删除控制器
kubctl get pod                                                        #查看pod状态 控制器删除后 pod也会被清楚

kubectl get svc 会看到 sve负责当前的负载均衡和对外暴漏

注意 名为kubenretes的svc不能删除 一旦删除 pod就无法访问kubenretes

kubectl create deployment nginx --image=wangyanglinux/myapp：v1 --dry-run -o yaml #--dry-run 仅测试不执行 用于测试命令 -o yaml 以yaml格式进行输出 如果写-o json 则以json格式输出

k8s中所有的内容都抽象为资源，资源实体化后，叫做对象

kubectl get pod -n kube-system                             #这个名称空间内存放着所有的k8s集群的组件
kubectl get pod --all-namespaces                           #查看不同名称空间里的资源
kubectl get pod -o wide                                    #查看详细的pod信息
kubectl get pod --show-labels                              #查看标签
kubectl get pod -l app                                     #列出包含app key的有哪些 只看某一类标签
kubectl get pod -w                                         #监控信息

在 k8s 中，一般使用 yaml 格式的文件来创建符合我们预期期望的 pod ，这样的 yaml 文件我们一般称为资源清单

apiVersion: group/apiversion  # 如果没有给定 group 名称，那么默认为 core，可以使用 kubectl api-versions # 获取当前 k8s 版本上所有的 apiVersion 版本信息( 每个版本可能不同 )    
kind:       #资源类别
metadata：  #资源元数据
   name
   namespace
   lables
   annotations   # 主要目的是方便用户阅读查找
spec: # 期望的状态（disired state）
status：# 当前状态，本字段有 Kubernetes 自身维护，用户不能去定义

获取 apiversion 版本信息 查看接k8s所有的接口组

[root@k8s-master01 ~]# kubectl api-versions 
admissionregistration.k8s.io/v1beta1
apiextensions.k8s.io/v1beta1
apiregistration.k8s.io/v1
apiregistration.k8s.io/v1beta1
apps/v1
......(以下省略)

获取资源的 apiVersion 版本信息

[root@k8s-master01 ~]# kubectl explain pod
KIND:     Pod
VERSION:  v1
.....(以下省略)

[root@k8s-master01 ~]# kubectl explain Ingress
KIND:     Ingress
VERSION:  extensions/v1beta1

获取字段设置帮助文档

[root@k8s-master01 ~]# kubectl explain pod
KIND:     Pod
VERSION:  v1

DESCRIPTION:
     Pod is a collection of containers that can run on a host. This resource is
     created by clients and scheduled onto hosts.

FIELDS:
   apiVersion    <string>
     ........
     ........

字段配置格式

apiVersion <string>          #表示字符串类型
metadata <Object>            #表示需要嵌套多层字段
labels <map[string]string>   #表示由k:v组成的映射
finalizers <[]string>        #表示字串列表
ownerReferences <[]Object>   #表示对象列表
hostPID <boolean>            #布尔类型
priority <integer>           #整型
name <string> -required-     #如果类型后面接 -required-，表示为必填字段

apiVersion: v1
kind: Pod
metadata:
  name: pod-demo
  namespace: default
  labels:
    app: myapp
    version: v1
spec:
  containers:
  - name: myapp-1
    image: wangyanglinux/myapp:v1
  - name: busybox-1
    image: busybox:v1
    command:
    - "/bin/sh"
    - "-c"                           #将后面的命令作为一条执行 如果是-e 则是用于判断返回码是否为0如不为零则脚本自动退出
    - "sleep 3600"

kubectl get pod xx.xx.xx -o yaml  
<!--使用 -o 参数 加 yaml，可以将资源的配置以 yaml的格式输出出来，也可以使用json，输出为json格式--> 
kubectl get pod -o wide
查看pod的详细信息

通过yeml文件创建pod

kubectl create -f xxxxx.yeml  
kubectl describe pod nginx-pod           #查看对象的详细信息
kubectl logs  pod名称 -c  容器名 -n 名称空间	              #查看日志 指定哪个pod -c 指定容器 -n 指定名称空间

时间序列 ： 1、创建pause 初始化网络栈和存储卷 和挂载

​ 2、初始化容器的创建init-c但创建后成功了就会离开 不会伴随整个pod的生命周期，init-c必须是一个线性过程 ，第一个没有启动成功那么第二个就不允许启动 init-c可以有多个 如果init-c-1成功了但是init-c-2容器失败了并不会重载init-c-2这个容器，而是重载整个pod 如果重启策略中写了Never 那么init失败之后不会重载该pod

​ （重启策略 spec.restartPollcy 字段类型：string 可选值 ：Always 无论pos因为什么关闭 都会重载 、OnFaliure pod以非零退出码终止时 会进行重载 、Never pod终止后kubelet将退出码发送给master 不会进行重载）

​ 3、创建核心代码容器man-c man-c可以有多个，理论上man-c是并行启动的但实际上man-c又是线性的一个过程并不能做到完全同时启动

探针：

​ 就绪探测： 探测容器是否准备好 就绪探测的生命周期是在man-c中的部分 一旦就绪 则不再探测

​ 存活探测：判断容器是否还可用 存货探测的生命周期是从man-c启动后一段时间开始 一直到man-c死亡

​ 每个man -c单独定义就绪探测和存货探测

启动前操作 ：

关闭前操作 ：发送信号 如 、解除挂载、 备份数据，使用kubelet发送优雅退出信号等操作

探针是kubelet对容器执行定期诊断，kubelet调用由容器实现的Handler 有以下三种类型的处理程序

1、ExecAction ：在容器中执行指定命令 如果命令退出时返回码为0则认为诊断成功

TCPSocketAction ：对指定端口上的容器的IP地址进行TCP检查，如果端口打开则诊断成功

HTTPGetAction ：对指定的端口和路径上的容器的IP执行HTTP Get 请求 如果响应的状态码大于200 且小于400 则认为诊断是成功的

livenessProbe：探测容器是否正常运行 如果正常运行则静默 如果探测失败，则kubelet会杀死容器，并且容器将收到重启策略的影响，如果容器不提供存货探针则 默认状态为Success

readinessProbe：探测容器是否准备好服务请求，如果就绪探测失败 ，断电控制器将从与pod匹配的所有Service的端点中删除该pod的IP地址，初始延迟之前的就绪状态默认为Failure ，如果容器不提供就绪探针 则默认为Success

kubectl exec -it pod名称  -c 容器名 -- /bin/sh          进入容器个命令 格式	

以yeml格式创建的资源清单文件 正常命名应该是 xxx.pod.yeml 但在linux中 .yeml后缀可以省略不写

RC （ReplicationController ）主要的作用就是用来确保容器应用的副本数始终保持在用户定义的副本数 。即如果有容器异常退出，会自动创建新的Pod来替代；而如果异常多出来的容器也会自动回收

Kubernetes 官方建议使用 RS（ReplicaSet ） 替代 RC （ReplicationController ） 进行部署，RS 跟 RC 没有本质的不同，只是名字不一样，并且 RS 支持集合式的 selector

apiVersion: v1
kind: ReplicationController
metadata:
  name: frontend
spec:
  replicas: 3
  selector:
    app: nginx                                 #标签 控制器通过标签匹配自己的pod 确保容器内的副本数满足用户期望
  template:
    metadata:
      labels:
        app: nginx                             #标签 在RC中 pod的标签要和控制器所匹配的标签完全一致
    spec:
      containers:
      - name: php-redis
        image: wangyanglinux/myapp:v1
        env:
        - name: GET_HOSTS_FROM
          value: dns
          name: zhangsan
          value: "123"
        ports:
        - containerPort: 80

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      tier: frontend                #标签 用于匹配pod 
  template:
    metadata:
      labels:
        app: nginx                 #标签 RS中pod的标签可以有多个 只要有一个和控制器指定的匹配即可
        tier: frontend
        version: V1                #标签 也可以只有一个 全集也是子集的一种
    spec:
      containers:
      - name: myapp
        image: wangyanglinux/myapp:v1
        env:
        - name: GET_HOSTS_FROM
          value: dns
        ports:
        - containerPort: 80

deployment并不会直接创建pod，deployment会创建一个RS控制器，由RS控制器来创建pod 滚动更新时会创建一个新的RS控制器，将旧版的期望转移至新版 回收旧的RS创建的pos 新的RS会创建新的pod 默认会保留旧版本的RS控制器 以提供回滚功能

Deployment 为 Pod 和 ReplicaSet 提供了一个声明式定义(declarative)方法，用来替代以前的ReplicationController 来方便的管理应用。典型的应用场景包括：

• 定义Deployment来创建Pod和ReplicaSet
• 滚动升级和回滚应用
• 扩容和缩容
• 暂停和继续Deployment

Ⅰ、部署一个简单的 Nginx 应用

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: nginx-deployment
spec:
  replicas: 3
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

kubectl create -f https://kubernetes.io/docs/user-guide/nginx-deployment.yaml --record
## --record参数可以记录命令，我们可以很方便的查看每次 revision 的变化

Ⅱ、扩容

kubectl scale deployment nginx-deployment --replicas 10      #扩容和缩容使用的是同一条命令 扩容并不会创建新的RS控制器

Ⅲ、如果集群支持 horizontal pod autoscaling 的话，还可以为Deployment设置自动扩展

kubectl autoscale deployment nginx-deployment --min=10 --max=15 --cpu-percent=80

Ⅳ、更新镜像也比较简单

kubectl set image deployment/nginx-deployment nginx=nginx:1.9.1

Ⅴ、回滚

kubectl rollout undo deployment/nginx-deployment

滚动更新 ：将创建这个deployment的yeml文件复制并修改内部的版本信息 命名方式根据公司需求 之后应用新的yeml文件就可以了

​ 使用 kubectl apply -f 新文件名进行滚动更新

回滚 ： 使用想要降级的版本的yeml文件

​ 使用kubectl apply -f 老版本文件名 即可进行回滚

命令式定义 写好的顺序 必须按照顺序执行

声明式定义 指定了一个目标 目标如何到达由他自己判断

deployment支持声明声明式定义 使用

 kubectl apply -f 指定文件                       #apply会自动降级 如果它创建的这个文件不支持声明式定义则会将为命令式的

假如您创建了一个有5个niginx:1.7.9 replica的 Deployment，但是当还只有3个nginx:1.7.9的 replica 创建出来的时候您就开始更新含有5个nginx:1.9.1 replica 的 Deployment。在这种情况下，Deployment 会立即杀掉已创建的3个nginx:1.7.9的 Pod，并开始创建nginx:1.9.1的 Pod。它不会等到所有的5个nginx:1.7.9的 Pod 都创建完成后才开始改变航道

在更新时 根据资源清单定义的期望 可以多也可以少 并非是保持和期望一致的pod数量 在老版本中可以最多多一个或少一个，但在新版本中可以多25%或少25%（滚动幅度从1个 变为了整体的25% 留下75%保持客户访问）

无状态服务如apache tomcat等 都可以使用deployment进行部署

DaemonSet 确保全部（或者一些）Node 上运行一个 Pod 的副本。当有 Node 加入集群时，也会为他们新增一个 Pod 。当有 Node 从集群移除时，这些 Pod 也会被回收。删除 DaemonSet 将会删除它创建的所有 Pod

使用 DaemonSet 的一些典型用法：

• 运行集群存储 daemon，例如在每个 Node 上运行 glusterd、ceph
• 在每个 Node 上运行日志收集 daemon，例如fluentd、logstash
• 在每个 Node 上运行监控 daemon，例如 Prometheus Node Exporter、collectd、Datadog 代理、New Relic 代理，或 Ganglia gmond

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: deamonset-example
  labels:
    app: daemonset
spec:
  selector:
    matchLabels:
      name: deamonset-example
  template:
    metadata:
      labels:
        name: deamonset-example
    spec:
      containers:
      - name: daemonset-example
        image: wangyanglinux/myapp:v1

Job 负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个 Pod 成功结束

• spec.template格式同Pod
• RestartPolicy仅支持Never或OnFailure
• 单个Pod时，默认Pod成功运行后Job即结束
• .spec.completions标志Job结束需要成功运行的Pod个数，默认为1
• .spec.parallelism标志并行运行的Pod的个数，默认为1
• spec.activeDeadlineSeconds标志失败Pod的重试最大时间，超过这个时间不会继续重试

Example

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  template:
    metadata:
      name: pi
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl",  "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never

• spec.template格式同Pod
• RestartPolicy仅支持Never或OnFailure
• 单个Pod时，默认Pod成功运行后Job即结束
• .spec.completions标志Job结束需要成功运行的Pod个数，默认为1
• .spec.parallelism标志并行运行的Pod的个数，默认为1
• spec.activeDeadlineSeconds标志失败Pod的重试最大时间，超过这个时间不会继续重试

Cron Job 管理基于时间的 Job，即：

• 在给定时间点只运行一次
• 周期性地在给定时间点运行

使用条件：当前使用的 Kubernetes 集群，版本 >= 1.8（对 CronJob） 对于软件更新 看新版和旧版的性能是否有变化 是否需要使用新功能 是否修复了bug 机房内的服务器尽量不要重启 避免造成起不来的情况

典型的用法如下所示：

• 在给定的时间点调度 Job 运行
• 创建周期性运行的 Job，例如：数据库备份、发送邮件

• .spec.schedule：调度，必需字段，指定任务运行周期，格式同 Cron

• .spec.jobTemplate：Job 模板，必需字段，指定需要运行的任务，格式同 Job

• .spec.startingDeadlineSeconds ：启动 Job 的期限（秒级别），该字段是可选的。如果因为任何原因而错过了被调度的时间，那么错过执行时间的 Job 将被认为是失败的。如果没有指定，则没有期限

• .spec.concurrencyPolicy：并发策略，该字段也是可选的。它指定了如何处理被 Cron Job 创建的 Job 的并发执行。只允许指定下面策略中的一种：

  • Allow（默认）：允许并发运行 Job
  • Forbid：禁止并发运行，如果前一个还没有完成，则直接跳过下一个
  • Replace：取消当前正在运行的 Job，用一个新的来替换

  注意，当前策略只能应用于同一个 Cron Job 创建的 Job。如果存在多个 Cron Job，它们创建的 Job 之间总是允许并发运行。

• **.spec.suspend ：挂起，该字段也是可选的。如果设置为 true，后续所有执行都会被挂起。它对已经开始执行的 Job 不起作用。默认值为 false。 ** 挂起和关闭的区别 挂起会把数据持久化到磁盘 关闭数据会清空

• .spec.successfulJobsHistoryLimit 和 .spec.failedJobsHistoryLimit ：历史限制，是可选的字段。它们指定了可以保留多少完成和失败的 Job。默认情况下，它们分别设置为 3 和 1。设置限制的值为 0，相关类型的 Job 完成后将不会被保留。

Example

apiVersion: batch/v1beta1
kind: CronJob
metadata:
  name: hello
spec:
  schedule: "*/1 * * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: hello
            image: busybox
            args:
            - /bin/sh
            - -c
            - date; echo Hello from the Kubernetes cluster
          restartPolicy: OnFailure

$ kubectl get cronjob
NAME      SCHEDULE      SUSPEND   ACTIVE    LAST-SCHEDULE
hello     */1 * * * *   False     0         <none>
$ kubectl get jobs
NAME               DESIRED   SUCCESSFUL   AGE
hello-1202039034   1         1            49s
$ pods=$(kubectl get pods --selector=job-name=hello-1202039034 --output=jsonpath={.items..metadata.name})
$ kubectl logs $pods
Mon Aug 29 21:34:09 UTC 2016
Hello from the Kubernetes cluster

# 注意，删除 cronjob 的时候不会自动删除 job，这些 job 可以用 kubectl delete job 来删除
$ kubectl delete cronjob hello
cronjob "hello" deleted

创建 Job 操作应该是 幂等的

Kubernetes Service 定义了这样一种抽象：一个 Pod 的逻辑分组，一种可以访问它们的策略 —— 通常称为微服务。 这一组 Pod 能够被 Service 访问到，通常是通过 Label Selector

微服务：将内部的服务体系从一个大块 抽象成多个细分小块 便于维护升级等操作

Service能够提供负载均衡的能力，但是在使用上有以下限制：

• 只提供 4 层负载均衡能力，而没有 7 层功能，但有时我们可能需要更多的匹配规则来转发请求，这点上 4 层负载均衡是不支持的

• ClusterIp：默认类型，自动分配一个仅 Cluster 内部可以访问的虚拟 IP
• NodePort：在 ClusterIP 基础上为 Service 在每台机器上绑定一个端口，这样就可以通过 : NodePort 来访问该服务
• **LoadBalancer：在 NodePort 的基础上，借助 cloud provider 创建一个外部负载均衡器，并将请求转发到: NodePort ** NodePort的端口必须在30000以上
• ExternalName：把集群外部的服务引入到集群内部来，在集群内部直接使用。没有任何类型代理被创建，这只有 kubernetes 1.7 或更高版本的 kube-dns 才支持

在 Kubernetes 集群中，每个 Node 运行一个 kube-proxy 进程。kube-proxy 负责为 Service 实现了一种 VIP（虚拟 IP）的形式，而不是 ExternalName 的形式。 在 Kubernetes v1.0 版本，代理完全在 userspace。在 Kubernetes v1.1 版本，新增了 iptables 代理，但并不是默认的运行模式。 从 Kubernetes v1.2 起，默认就是 iptables 代理。 在 Kubernetes v1.8.0-beta.0 中，添加了 ipvs 代理

在 Kubernetes 1.14 版本开始默认使用 ipvs 代理

在 Kubernetes v1.0 版本，Service 是 “4层”（TCP/UDP over IP）概念。 在 Kubernetes v1.1 版本，新增了 Ingress API（beta 版），用来表示 “7层”（HTTP）服务

这种模式，kube-proxy 会监视 Kubernetes Service 对象和 Endpoints ，调用 netlink 接口以相应地创建 ipvs 规则并定期与 Kubernetes Service 对象和 Endpoints 对象同步 ipvs 规则，以确保 ipvs 状态与期望一致。访问服务时，流量将被重定向到其中一个后端 Pod

与 iptables 类似，ipvs 于 netfilter 的 hook 功能，但使用哈希表作为底层数据结构并在内核空间中工作。这意味着 ipvs 可以更快地重定向流量，并且在同步代理规则时具有更好的性能。此外，ipvs 为负载均衡算法提供了更多选项，例如：

• rr：轮询调度
• lc：最小连接数
• dh：目标哈希
• sh：源哈希
• sed：最短期望延迟
• nq： 不排队调度

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-v02oHSgw-1654622605006)(E:\学习视频\课件\k8s\Png\ipvs.png)]

clusterIP 主要在每个 node 节点使用 iptabels，将发向 clusterIP 对应端口的数据，转发到 kube-proxy 中。然后 kube-proxy 自己内部实现有负载均衡的方法，并可以查询到这个 service 下对应 pod 的地址和端口，进而把数据转发给对应的 pod 的地