K8s学习笔记（一）

IaaS（Infrastructure as a Service）：基础设施即服务。如，阿里云。
PaaS（Platform as a service）：平台即服务。如，新浪云。
SaaS（Software as a Service）：软件设施即服务。如，Office。

K8s：是一个开源的，用于管理云平台中多个主机上的容器化的应用。
特点：轻量级，资源消耗小；开源；弹性伸缩；负载均衡

K8s架构

Master
Api Server：所有服务访问统一入口
Controller Manager：维持副本期望数目
Scheduler：负责接受任务，选择合适的节点进行分配任务
ETCD：键值对数据库，存储K8s集群所有重要信息（持久化）
Node
Kubelet：直接跟容器引擎（Docker）交互，实现容器的生命周期管理
Kube-proxy：负责写入规则至 IPTABLES、IPVS
其他插件
CoreDNS：可以为集群中的SVC创建一个域名IP的对应关系解析
Dashboard：给K8s集群提供一个B/S结构访问体系
Ingress Controller：官方只能实现四层代理，Ingress可以实现七层代理
Federation：提供一个可以跨集群中心多K8s统一管理功能
Prometheus：提供K8s集群的监控能力
ELK：提供K8s集群日志统一分析接入平台

网络通讯模式

• 同一个Pod内部通讯：同一个Pod共享同一个网络命名空间，共享同一个Linux协议栈

• Pod之间通讯：

  • Pod1与Pod2不在同一台主机，Pod的地址是与Docker0在同一网段的，但Docker0网段与宿主机网卡是两个完全不同的网段，并且不同Node之间的通信只能通过宿主机的无网卡进行。将Pod的IP和所在Node的IP关联起来，通过这个关联让Pod可以互相访问。
  • Pod1与Pod2在同一台主机，由Docker0网桥直接转发请求至Pod2，不需要经过Flannel。

• Pod至Service的网络：IPtables维护和转发。

• Pod到外网：Pod向外网发送请求，查找路由表，转发数据包到宿主机的网卡，宿主网卡完成路由选择后，IPtables执行Masquerade，把源IP更改为宿主网卡IP，然后向外网发送服务请求。

• 外网访问Pod：Service

创建Pod常用字段

必备属性

参数名	类型	说明
apiVersion	String	K8s API的版本，目前基本是v1，可以用kubectl api-versions命令查询
kind	String	yaml文件定义的资源类型和角色，如Pod，Service
metadata	Object	元数据对象
metadata.name	String	元数据对象名，如命名Pod
metadata.namespace	String	元数据对象命名空间
spec	Object	详细定义对象
spec.containers[]	list	spec对象的容器列表定义
spec.containers[].image	String	镜像名

可用属性

参数名	类型	说明
spec.containers[].name	String	容器名
spec.containers[].imagePullPolicy	String	镜像拉取策略： 1. Always（默认）：每次都重新拉取镜像 2. Never：仅使用本地镜像 3. IfNotPresent：如果本地有就使用本地镜像，没有就拉取在线镜像
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	设置存储卷路径的读写模式，true或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[].protocal	String	端口协议，支持TCP（默认）和UDP
spec.containers[].env[]	List	容器的环境变量列表
spec.containers[].env[].name	String	环境变量名
spec.containers[].env[].value	String	环境变量值
spec.restartPolicy	String	Pod重启策略： 1. Always（默认）：Pod一旦终止，无论容器如何终止，kubelet服务都重启它 2. OnFailure：只有Pod以非零退出码终止时，kubelet才会重启该容器。如果容器正常结束（退出码为0），kubelet不重启它。 3. Never：Pod终止后，kubelet将退出码报告给Master，不会重启该Pod
spec.nodeSelector	Object	Node的Lable过滤标签，以key:value格式指定
spec.imagePullSecrets	Object	拉取镜像时使用的secret名称，以name:secretkey格式指定
spec.hostNetwork	Boolean	是否使用主机网络模式，默认false。true表示使用宿主机网络，不使用docker网桥，同时将无法在同一台宿主机上启动第二个副本

---

Pod生命周期

初始化容器

Pod可以具有多个容器，应用运行在容器里面，但应用容器运行前可能有一个或多个初始化容器先启动。

特点：
Init容器总是运行到成功完成为止。
每个init容器都必须在下一个init容器启动前成功完成。

说明：
若Pod的Init容器失败，Kubernetes会不断重启该Pod，直到Init容器成功为止，除非将Pod属性restartPolicy设置为Never。
如果Pod重启，所有Init容器必须重新执行。
Init容器可以共用一个端口但不能共用容器名。

初始化容器举例

init-pod.yaml

apiVersion: v1
kind: Pod
metadata:
  name: myapp-pod
  lables:
    app: myapp
spec:
  containers:
  - name: myapp-container
    image: busybox
    command: ['sh','-c','echo The app is running! && sleep 3600']
  initContainers:
  - name: init-myservice
    image: busybox
    command: ['sh','-c','until nslookup myservice; do echo waiting for myservice; sleep 2; done;']
  - name: init-mydb
    image: busybox
    command: ['sh','-c','until nslookup mydb; do echo waiting for mydb; sleep 2; done;']

myservice.yaml

apiVersion: v1
kind: Service
metadata:
  name: myservice
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9376

mydb.yaml

apiVersion: v1
kind: Service
metadata:
  name: mydb
spec:
  ports:
    - protocol: TCP
      port: 80
      targetPort: 9377

init-pod.yaml中定义了2个init container与1个main container。运行yaml文件。

$ kubectl create -f myservice.yaml
$ kubectl create -f mydb.yaml
$ kubectl create -f init-pod.yaml

探针

探针是由kubelet对容器执行的定期诊断。要执行诊断，kubelet调用由容器实现的Handler。

三种类型的处理程序：

• ExecAction：在容器内执行命令。退出时返回码为0，则诊断为成功。
• TCPSocketAction：对指定端口上的容器IP地址进行TCP检查。端口打开，则诊断为成功。
• HTTPGetAction：对指定端口和路径上的容器IP地址执行HTTP Get请求。如果响应的状态码大于等于200且小于400，则诊断为成功。

三种诊断结果：成功，失败，未知（不采取任何行动）。

探测方式-livenessProbe

指示容器是否正在运行。如果存活探测失败，则kubelet会杀死容器，且容器受重启策略影响。若容器不提供存活探针，默认状态为Success。
livenessProbe-exec

apiVersion: v1
kind: Pod
metadata:
  name: liveness-exec-pod
  namespace: default
spec:
  containers:
  - name: liveness-exec-container
    image: busybox
    imagePullPolicy: IfNotPresent
    command: ['/bin/sh','-c','touch /tmp/live; sleep 60; rm -rf /tmp/live; sleep 3600']
    livenessProbe:
      exec:
        command: ['test','-e','/tmp/live']
      initialDelaySeconds: 1
      periodSeconds: 3

流程：创建容器 - 创建文件 - 探测存活 - 60s后删除文件 - 存活探测失败 - 杀死容器 - 重新创建容器（循环）

livenessProbe-httpget

apiVersion: v1
kind: Pod
metadata:
  name: liveness-httpget-pod
  namespace: default
spec:
  containers:
  - name: liveness-httpget-container
    image: linux/myapp:v1
    imagePullPolicy: IfNotPresent
    ports:
    - name: http
      containerPort: 80
    livenessProbe:
      httpGet:
        port: 80
        path: /index.html
      initialDelaySeconds: 1
      periodSeconds: 3
      timeoutSeconds: 10

流程：创建容器 - Pod运行 - 检测存活 - 手动删除index.html - 检测失败 - 杀死容器 - 重新创建容器（循环）

livenessProbe-tcp

apiVersion: v1
kind: Pod
metadata:
  name: liveness-tcp-pod
spec:
  containers:
  - name: liveness-tcp-container
    image: linux/myapp:v1
    imagePullPolicy: IfNotPresent
    livenessProbe:
      httpSocket:
        port: 80
      initialDelaySeconds: 1
      periodSeconds: 3
      timeoutSeconds: 10

探测方式-readinessProbe

readinessProbe：指示容器是否就绪。如果就绪探测失败，端点控制器将从与Pod匹配的所有Service端点中删除该Pod的IP地址。初始延迟之前的就绪状态默认为Failure。如果容器不提供就绪探针，则默认为Success。
例：
readinessProbe-httpget

apiVersion: v1
kind: Pod
metadata:
  name: readiness-httpget-pod
  namespace: default
spec:
  containers:
  - name: readiness-httpget-container
    image: linux/myapp:v1
    imagePullPolicy: IfNotPresent
    readinessProbe:
      httpGet:
        port: 80
        path: /index1.html
      initialDelaySeconds: 1
      periodSeconds: 3

这里的镜像myapp:v1的目录中不存在文件index.html，因此Pod一直无法进入Ready状态，容器一直重启，直到出现index1.html才进入ready状态。

Start Stop

apiVersion: v1
kind: Pod
metadata:
  name: lifecycle-demo
spec:
  containers:
  - name: lifecycle-demo-container
    image: nginx
    lifecycle:
      postStart:
        exec:
          command: ['bin/sh','-c','echo Hello from the portStart handler > /usr/share/message']
      preStop:
        exec:
          command: ['bin/sh','-c','echo Hello from the portStop handler > /usr/share/message']

Pod phase可能存在的值

Pending：Pod已被kubernetes系统接受，但有一个或者多个容器镜像尚未创建。等待时间包括调度Pod的时间和通过网络下载镜像的时间
Running：该Pod已经绑定到了一个节点上，Pod中所有容器都已被创建。至少有一个容器正在运行，或正处于启动或重启状态
Succeeded：Pod中所有容器都被成功终止，且不会再重启
Failed：Pod中所有容器都已终止，且至少有一个容器时因为失败终止（容器以非0状态退出或被系统终止）
Unknown：因为某些原因无法取得Pod的状态，通常因为Pod所在主机通信失败

---

资源控制器

ReplicationController & ReplicaSet & Deployment

ReplicationController：用来确保容器应用的副本数始终保持在用户定义的副本数。如果有容器异常退出，会自动创建新的Pod替代；如果异常多出来的容器也会自动回收。
ReplicaSet：与ReplicationController类似，但ReplicaSet支持集合式的selector。新版本K8s建议使用ReplicaSet取代ReplicationController。
Deployment：建议使用Deployment自动管理ReplicaSet，这样无需担心跟其他机制的不兼容问题。Deployment支持滚动更新。

ReplicaSet

apiVersion: v1
kind: ReplicaSet
metadata:
  name: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels:
        tier: frontend
    spec:
      containers:
      - name: php-redis
        image: gcr.io/google_samples/gb-frontend:v3
        env:
        - name: GET_HOSTS_FROM
          value: dns
        ports:
        - containerPort: 80

副本数目监控以标签为准。

$ kubectl delete pod --all 
$ kubectl label pod frontend-m8hpc tier=frontend1 --overwrite=True

删除Pod或修改Pod标签，RS会重新创建Pod，维持副本数不变。

Deployment

apiVersion: v1
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 scale deployment nginx-deployment --replicas 10

如果集群支持HPA，还可以为Deployment设置自动扩展

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

更新镜像（创建一个新的rs）

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

回滚（回滚至前一个版本）

$ kubectl rollout undo deployment/nginx-deployment
$ kubectl rollout status deployment/nginx-deployment #查看Deployment是否完成
$ kubectl rollout history deployment/nginx-deployment #查看历史版本
$ kubectl rollout undo deployment/nginx-deployment --to-revision=2 #回滚到指定的历史版本
$ kubectl rollout pause deployment/nginx-deployment #暂停deployment的更新

注意

• Deployment可以保证在升级时只有一定数量的Pod是down的。会确保至少有比期望的Pod数量少一个是up状态（最多一个不可用）。
• Deployment可以确保只创建出超过期望数量的一定数量的Pod。会确保最多有比期望的Pod数量多一个是up状态（最多一个surge）。
• Rollover：若在Deployment还未创建完成时，就更新新的版本，Deployment会杀掉已创建的旧版本Pod，立即创建新版本Pod
• 清理Policy：可以通过设置revisionHistoryLimit来指定deployment最多保留多少revision历史记录。默认保留所有revision；若设revision为0，Deployment就不允许回退了

DaemonSet

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

• 在每个Node上运行集群存储Daemon
• 在每个Node上运行日志收集Daemon
• 在每个Node上运行监控Daemon

apiVersion: v1
kind: DaemonSetSet
metadata:
  name: deamonset-example
  labels: 
    app: daemonset
spec:
  selector:
    matchLabels:
      name: daemonset-example
  template:
    metadata:
      labels:
        name: daemonset-example
    spec:
      containers:
      - name: daemonset-example
        image: nginx:1.7.9

metadata.name与matchLabels.name必须匹配

Job，Cronjob

Job

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

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

apiVersion: v1
kind: Job
metadata:
  name: pi
spec:
  template:
    metadata:
      name: pi
    spec:
      containers:
      - name: pi
        image: perl
        #计算圆周率后2000位
        command: ["perl","-Mbignum=dpi","-wle","print bpi(2000)"]
      restartPolicy: Never

Cronjob

Cron Job管理基于时间的Job，在特定的时间循环创建Job即：

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

特殊说明：
RestartPolicy仅支持Never或OnFailure
单个Pod时，默认Pod成功运行后Job即结束
spec.template格式同Pod
spec.completions：标志Job结束需要成功运行的Pod个数，默认为1
spec.parallelism：标志并运行的Pod个数，默认为1
spec.activeDeadlineSeconds：标志失败Pod的重试最大时间，超过这个时间不会继续重试
spec.schedule：调度，必需字段，指定任务运行周期，格式 "*/1 * * * *"表示每分钟
spec.jobTemplate：Job模板，必需字段，指定需要运行的任务，格式同Job
spec.startingDeadlineSeconds：启动Job的期限（秒级别），可选字段。如果因为任何原因错过了被调度的时间，那么错过执行时间的Job将被认为是失败的。如果没有指定，则没有期限。
spec.concurrencyPolicy：并发策略，可选字段。它指定了如何处理被CronJob创建的Job并发执行。只允许指定下面策略中的一种：
　　Allow（默认）：允许并发运行Job
　　Forbid：禁止并发运行，如果前一个还没有完成，则直接跳过下一个
　　Replace：取消当前正在运行的Job，用一个新的来替换
spec.suspend：挂起，可选字段。如果设置为true，后续所有执行都会被挂起。它对已经开始执行的Job不起作用。默认值为false
spec.successfulJobHistoryLimit和spec.failedJobHistoryLimit：历史限制，可选字段。指定了可以保留多少完成和失败的Job。默认情况下，它们分别设置为3和1。设置限制的值为0，相关类型的Job完成后将不会保留

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

StatefulSet

StatefulSet作为Controller为Pod提供唯一的标识。可以保证部署和scale的顺序。
为有状态服务而设计，其应用场景包括：

• 稳定的持久化存储，即重新调度后还能访问到相同的持久化数据（基于PVC实现）
• 稳定的网络标志，即重新调度后PodName和HostName不变（基于Headless Service实现）
• 有序部署，有序扩展，即在部署或扩展的时候要依据定义的顺序（0至N-1）依次进行（基于init containers实现）
• 有序收缩，有序删除（N-1至0）

Horizontal Pod Autoscaling（HPA）

仅适用于Deployment和ReplicaSet。v1版本中，支持根据Pod的CPU利用率扩缩容；v1alpha版本中，支持根据内存和用户自定义的metric扩缩容。

参考资料

尚硅谷Kubernetes（k8s基于最新2019年8月发布的1.15.1）https://www.bilibili.com/video/av66617940