云原生技术 Docker、K8S

容器的三大好处

1.资源隔离与利用率提升
2.秒级弹性
3.环境一致性，简化交付

容器底层关键技术--Linux Cgroup
Docker使用Linux Cgroup 技术来实现容器实例的资源管理
1.memory:限制cgroup中的任务所使用的内存上限
2.cpu：使用调度程序提供对CPU的cgroup任务访问
3.Cpuset:为cgroup中的任务分配独立CPU和内存节点
4.Blkio:为块设备设定输入/输出限制

容器底层关键技术--Linux Namespace
1.PID namespace:隔离不同用户的进程，不同的namespace中可以有相同的pid
2.UTS namespace:允许每个容器拥有独立的hostname和domain name,使其在网络上可以被视为独立的节点
3.IPC namespace:保证容器间的进程交互，进行信号量、消息队列和共享内存的隔离
4.Network namespace:实现网路隔离，每个net namespace有独立的network devices,ip addresses,ip routing tables,/proc/net 目录
5.Mount namespace:隔离不用namespace的进程看到的目录结构，每个namespace的容器在/proc/mounts的信息只包含所在的namespace的mount point
6.User namespace:允许每个容器可以有不同的user和group id

容器底层关键技术--联合文件系统
概念：一个基于文件的接口，通过把一组目录交错起来，形成一个单一的视图
优点：
    1.多个容器可以共享image存储，节省存储空间
    2.部署多个容器时，base image可以避免多次拷贝，实现快速部署Docker目前支持的联合文件系统种类包括devicemapper、overlay2、aufs、btrfs、vfs

kubernets模型对象

Pod：能够创建、调度和管理的最小部署单元，是一组容器的集合，而不是单独的应用容器
     同一个Pod里的容器共享同一个网络命名空间、IP地址及端口空间
从生命周期来说，Pod是短暂的而不是长久的应用。Pods被调度到节点，保持在这个节点上直到被销毁

Pod详解--容器
容器分类：
1、Infrastructure Container：基础容器
   用户不可见，无需感知
   维护这个Pod网络空间
2、InitContainer:初始化容器，一般用于服务等待处理以及注册Pod信息等
   先于业务容器开始执行
   顺序执行，执行成功退出(exit 0),全部执行成功后开始启动业务容器
3、Containers:业务容器
   并行启动，启动成功后一直Running

容器基本组成
spec:
  imagePullSecrets:
  - name: default-secret
  containers:
  - image: kube-dns:1.0.0
    imagePullPolicy: IfNotPresent
    command:
    - /bin/sh
    - -c
    - /kube-dns 1>>/var/log/skydns.log 2>&1 --domain=cluster.local. --dns-port=10053
    --config-dir=/kube-dns-config --v=2
    resources:
      limits:
        cpu: 100m
        memory: 512Mi
      requests:
        cpu: 100m
        memory: 100Mi
  - livenessProbe:
      failureThreshold: 5
      exec:
      command:
      - “/bin/sh”,
      - “-c”
      - “echo ‘iam ok’”
      initialDelaySeconds: 60
      periodSeconds: 10
      successThreshold: 1
      timeoutSeconds: 5
    readinessProbe:
      failureThreshold: 3
      httpGet:
        path: /readiness
        port: 8081
        scheme: HTTP
      initialDelaySeconds: 3
      periodSeconds: 10
      successThreshold: 1
      timeoutSeconds: 5
- env:
      - name: APP_NAME
        value: test
      - name: USER_NAME
        valueFrom:
          secretKeyRef:
            key: username
            name: secret
     envFrom:
     - configMapRef:
         name: config
     volumeMounts:
     - mountPath: /usr/local/config
       name: cfg
     - mountPath: /usr/local/secret
       name: sct
- mountPath: /usr/local/disk
       name: pvc-153085714479448980   
- mountPath: /usr/local/host
       name: host 
    volumes:
    - configMap:
      defaultMode: 420
      items:
      - key: age
        path: age
        name: config
      name: cfg
    - name: sct
      secret:
        defaultMode: 420
        secretName: secret
- name: pvc-153085714479448980
  persistentVolumeClaim:
        claimName: pvc-153085714479448980 
- name: host
      hostPath:
        path: /opt/
  dnsPolicy: ClusterFirst
 
镜像部分：
镜像地址和拉取策略
拉取镜像的认证凭据
imagePullSecrets:
- name: default-secret
containers:
- image: kube-dns:1.0.0
imagePullPolicy: IfNotPresent

启动命令：
command：替换docker容器的entrypoint
args：作为docker容器entrypoint的入参
command:
- /bin/sh
- -c
- /kube-dns 1>>/var/log/skydns.log 2>&1 --domain=cluster.local. --dns-port=10053
--config-dir=/kube-dns-config --v=2

计算资源：
请求值：调度依据
限制值：容器最大能使用的规格
resources:
limits:
  cpu: 100m
  memory: 512Mi
requests:
  cpu: 100m
  memory: 100Mi

健康检查：
分命令行方式、httpGet请求方式以及TCPSocket方式。
   1、业务探针（readinessProbe）
   探测不正常后，不会重启容器，只会拿掉服务后端的endpoints
    readinessProbe:
      failureThreshold: 3
      httpGet:
        path: /readiness
        port: 8081
        scheme: HTTP
      initialDelaySeconds: 3
      periodSeconds: 10
      successThreshold: 1
      timeoutSeconds: 5  
   2、存活探针（livenessProbe）
   探测不正常后，会重启容器
  - livenessProbe:
      failureThreshold: 5
      exec:
      command:
      - “/bin/sh”,
      - “-c”
      - “echo ‘iam ok’”
      initialDelaySeconds: 60
      periodSeconds: 10
      successThreshold: 1
      timeoutSeconds: 5

Pod详解-外部输入
Pod可以接收的外部输入方式：环境变量、配置文件以及密钥。
1、环境变量：使用简单，但一旦变更后必须重启容器。
   Key-value自定义
   From 配置文件（configmap）
   From 密钥（Secret）
- env:
      - name: APP_NAME
        value: test
      - name: USER_NAME
        valueFrom:
          secretKeyRef:
            key: username
            name: secret
     envFrom:
     - configMapRef:
         name: config  
2、以卷形式挂载到容器内使用，权限可控。
   配置文件（configmap）
   密钥（secret）
   配置文件、密钥大小不能超过1M
   Secret有类型区分，不同类型有不同校验方式，输入的value需base64加密  
     volumeMounts:
     - mountPath: /usr/local/config
       name: cfg
     - mountPath: /usr/local/secret
       name: sct
- mountPath: /usr/local/host
       name: host 
    volumes:
    - configMap:
      defaultMode: 420
      items:
      - key: age
        path: age
        name: config
      name: cfg
    - name: sct
      secret:
        defaultMode: 420
        secretName: secret
- name: host
      hostPath:
        path: /opt/

Pod详解-持久化存储
1、主机hostpath
   必须要求Pod调度到固定节点上
     volumeMounts:
- mountPath: /usr/local/disk
       name: pvc-153085714479448980
    volumes:
- name: pvc-153085714479448980
  persistentVolumeClaim:
        claimName: pvc-153085714479448980 
2、云存储
   多类型选择，如云硬盘，文件存储，对象存储等
   不用担心Pod迁移
     volumeMounts:
- mountPath: /usr/local/host
       name: host 
    volumes:
- name: host
      hostPath:
        path: /opt/   

Pod详解-服务域名发现
  dnsPolicy：Pod内域名解析的策略
  ClusterFirst：使用kube-dns作为域名解析服务器
  Default：使用节点（kubelet）指定的域名服务器解析域名
  ClusterFirstWithHostNet：当Pod使用主机网络部署时使用
 
spec:
  containers:
  dnsPolicy: ClusterFirst
 
Pod与工作负载的关系
  通过label-selector相关联
  Pod通过工作负载实现应用的运维，如伸缩、升级等
 
关键工作负载-ReplicaSet(无状态模式):
  ReplicaSet—副本控制器
  确保Pod的一定数量的份数(replica)在运行。如果超过这个数量，控制器会杀死一些，如果少了，控制器会启动一些。
  ReplicaSet用于解决pod的扩容和缩容问题。
  通常用于无状态应用

apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
  name: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      tier: frontend
    matchExpressions:
    - {key: tier, operator: In, values: [frontend]}  // NotIn, Exists, DoesNotExist
  template:
    metadata:
      labels:
        app: guestbook
        tier: frontend
    spec:
      containers:
      - name: php-redis
        image: gcr.io/google_samples/gb-
        frontend:v3
        resources:
          requests:
            cpu: 100m
            memory: 100Mi
        env:
        - name: GET_HOSTS_FROM
          value: dns
        ports:
        - containerPort: 80

关键工作负载-Deployment(无状态模式)
Kubernetes Deployment提供了官方的用于更新Pod和Replica Set（下一代的Replication Controller）的方法，您可以在Deployment对象中只描述您所期望的理想状态（预期的运行状态），
  Deployment控制器为您将现在的实际状态转换成您期望的状态;
Deployment集成了上线部署、滚动升级、创建副本、暂停上线任务，恢复上线任务，回滚到以前
  某一版本（成功/稳定）的Deployment等功能，在某种程度上，Deployment可以帮我们实现无人值守的上线，大大降低我们的上线过程的复杂沟通、操作风险。
Deployment的典型用例：
  使用Deployment来启动（上线/部署）一个Pod或者ReplicaSet
  检查一个Deployment是否成功执行
  更新Deployment来重新创建相应的Pods（例如，需要使用一个新的Image）
  如果现有的Deployment不稳定，那么回滚到一个早期的稳定的Deployment版本

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

关键工作负载-StatefulSet(有状态模式)
StatefulSet—有状态应用
用于解决各个pod实例独立生命周期管理，提供各个实例的启动顺序和唯一性
  稳定，唯一的网络标识符。
  稳定，持久存储。
  有序的，优雅的部署和扩展。
  有序，优雅的删除和终止。
  有序的自动滚动更新。
  严格的启动/删除顺序
 
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  selector:
    matchLabels:
      app: nginx # has to match .spec.template.metadata.labels
  serviceName: "nginx"
  replicas: 3 # by default is 1
  template:
    metadata:
      labels:
        app: nginx # has to match .spec.selector.matchLabels
    spec:
      terminationGracePeriodSeconds: 10
      containers:
      - name: nginx
        image: k8s.gcr.io/nginx-slim:0.8
        ports:
        - containerPort: 80
          name: web
      volumeMounts:
      - name: www
        mountPath: /usr/share/nginx/html
      volumeClaimTemplates:
      - metadata:
        name: www
        spec:
          accessModes: [ "ReadWriteOnce" ]
          storageClassName: "my-storage-class"

关键工作负载-DaemonSet（守护进程模式）
DaemonSet能够让所有（或者一些特定：NodeSelector或NodeAffinity指定Node）的Node节点运行同一个pod。当节点加入到kubernetes集群中，pod会被（DaemonSet）调度到该节点上运行，当节点从kubernetes集群中被移除，
被（DaemonSet）调度的pod会被移除，如果删除DaemonSet，所有跟这个DaemonSet相关的pods都会被删除。
在使用kubernetes来运行应用时，很多时候我们需要在一个区域（zone）或者所有Node上运行同一个守护进程（pod），例如如下场景：
  每个Node上运行一个分布式存储的守护进程，例如glusterd，ceph
  运行日志采集器在每个Node上，例如fluentd，logstash
  运行监控的采集端在每个Node，例如prometheus node exporter，collectd等
  支持滚动升级，支持级联/非级联删除
 
apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
  name: tomcat-ds
spec:
  template:
    metadata:
      labels:
        app: tomcat
    spec:
      containers:
      - name: tomcat
        image: tomcat:8.0.30-jre8
        ports:
        - containerPort: 8080

关键工作负载-Job
分为普通任务（Job）和定时任务（CronJob）
  一次性执行，非堵塞
  适合CI，视频解码，基因测序等业务
普通任务（Job）：
- 保证指定数量Pod成功运行结束 - completions
- 支持并行 - parallelism
- 支持错误自动重试（10s, 20s, 40s,… 6min）
- 删除Job会触发对应Pod删除
定时任务（CronJob）：
- 基于时间调度的Job（ Cron 格式）
- 用户可以暂停/恢复Job的周期性调度 .spec.suspend={true,false}
- 管理Job -> Pod

apiVersion: batch/v1
kind: Job
metadata:
  name: pi
spec:
  backoffLimit: 5
  activeDeadlineSeconds: 100
  template:
    metadata:
     name: pi
    spec:
      containers:
      - name: pi
        image: perl
        command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
      restartPolicy: Never
---  
apiVersion: batch/v1
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

 
 
Pod与服务的关系
通过label-selector相关联
通过服务实现Pod的负载均衡能力：
  Service：实现TCP/UDP 4层负载均衡能力
  Ingress：实现HTTP 7层负载均衡能力

Service定义了pods的逻辑集合和访问这个集合的策略。Pods集合是通过定义Service时提供的Label选择器完成的
Service的引入旨在保证pod的动态变化对访问端透明，访问端只需要知道service的地址，由service来提供代理
Service的抽象使得前端客户和后端Pods进行了解耦
支持ClusterIP，NodePort以及LoadBalancer三种类型：
ClusterIP
- 默认类型，自动分配集群内部可以访问的虚IP——Cluster IP。
NodePort
- 为Service在Kubernetes集群的每个Node上分配一个端口，即NodePort，集群内/外部
可基于任何一个NodeIP:NodePort的形式来访问Service。
LoadBalancer
- 需要跑在特定的cloud provider上
- Service Controller自动创建一个外部LB并配置安全组
- 对集群内访问，kube-proxy用iptables或ipvs实现了云服务提供商LB的部分功能：L4转发，
安全组规则等。

Service的底层实现有userspace、iptables和ipvs三种模式

kind: Service
apiVersion: v1
metadata:
  name: my-service
spec:
  selector:
    app: A
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376
    nodePort: 30061
  type: ClusterIP

Service类型： ClusterIP、NodePort、 LoadBalancer
Ingress:Ingress基于service实现7层路由转发能力
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: test
  annotations:
    ingress.kubernetes.io/rewrite-target: /
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - path: /foo
        backend:
          serviceName: service-a
          servicePort: 80
      - path: /bar
        backend:
          serviceName: service-b
          servicePort: 80

 
 
Kube-apiserver:是整个kubernetes集群的“灵魂”，是信息的汇集中枢，提供了所有内部和外部的API请求操作的唯一入口，同时也负责整个集群的认证、授权、访问控制、服务发现等等能力。

Kubernetes基于list-watch机制的控制器架构

Controller-manager:watch各类set,处理生命周期事件；定期list做同步处理，保证最终一致
Scheduler:list & watch集群中的node,供调度时使用；watch未调度的Pod,进行多策略调度,为Pod找到一个合适的Node
Kubelet:watch被调度到本节点的Pod，执行生命周期动作

1、kubectl调用api-server创建ReplicaSet---->
2、api-server在etcd创建ReplicaSet---->
3、etcd向api-server上报事件ReplicaSet Created---->
4.0、controller-manager向api-server发起watch ReplicaSet 4.1、api-server向controller-manager上报事件ReplicaSet Created---->
5、controller-manager调用api-server创建Pod---->
6、api-server在etcd创建Pod ---->
7、etcd 向api-server上报事件Pod Created---->
8.0、sheduler向api-server发起watch Pod(destNode="") 8.1、api-server向sheduler上报事件Pod Created---->
9、scheduler调用api-server更新Pod按调度结果绑定node---->
10、api-server在etcd更新Pod---->
11、etcd向api-server上报事件Pod Bound(Updated)---->
12.0、kubelet向api-server发起watch Pod(destNode="myNode") 12.1、api-server向kubelet上报事件Pod Bound(Updated)

scheduler调度器的内部流程:
1、通过NodeLister获取所有节点信息；
2、整合scheduled pods和assume pods，合并到pods，作为所有已调度Pod信息；
3、从pods中整理出node-pods的对应关系表nodeNameToInfo；
4、过滤掉不合适的节点；
5、给剩下的节点依次打分；
6、在分数最高的nodes中随机选择一个节点用于绑定。这是为了避免分数最高的节点被几次调度撞车 。