k8s

kubernetes

serverless
FaaS:函数即服务，调用时才激活，调用完成之后休眠状态

微服务
    动态服务发现，服务注册，服务调用

服务编排系统：将根据系统资源自身情况，将服务部署在合适的节点上       将应用程序打包成镜像，然后以容器方式运行，一次打包，到处运行
容器编排系统：单一容器没有太大的生产价值，把容器之间的依赖关系反应出来实现其价值。   容器的生命周期管理

K8S总览

master：一般起高可用的作用     
    APIserver、scheduler、controller、etcd（kv存储系统）  
	APIserver：数据库，容器的增删改查，无状态，可多实例，是唯一一个访问etcd存储的入口。作为整个集群的网关。所有其他组件的反馈首先到apiserver，然后再由apiserver写入到etcd中
    controller：会watch apiserver上的数据，然后进行下一步操作。        会比较用户期望的保存在etcd中的状态和系统中真正运行的实际的状态，如果不一致，controller会不遗余力的通过各种方式达到etcd中的状态			同时只能运行一个实例，leader
    control loop：死循环，每隔一段时间就会检查系统容器的健康状态
	用户下达的指令会保存在etcd中
node：一般起负载均衡的作用
    kubelet：会watch apiserver上的数据，如果监听到有容器需要在自己node上创建，就会通知docker，然后拉取镜像，进行容器的创建
	kube-proxy：k8s集群内部的负载均衡器，分布式代理服务器，每个node上部署一个容器，定时从etcd中获取server的信息，转换成iptables或ipvs规则，使得pod和service或者client和service之间的网络连通
DNS:service创建之后会把名称和ip注册到dns中，client访问通过查dns中的service名称即可
CNI（flannel...）


client--->service--->pod
    service和pod之间的关联是通过label，label selector
	
部署：
    各组件以守护进程方式部署
	各组件以pod方式部署

master，node
client--->master（apiserver）
registry：docker hub，gcr.io


kubectl config view
kubectl create deployment deploymentName
kubectl create service clusterip serviceName(必须和创建的deploymentNameserver一致) --tcp=nodePort:containerPort
kubectl scale --replicas=3 deployment deploymentName
kubectl api-versions
kubectl explain pods/deployment....


apiserver的6443端口

pod、pod controller、service
    pod controller： 
	    deployment
    

yaml字段：
    kind、apiVersion、metadata、spec、status
	

POD网络被client访问的三种方法：
    Service：NodePort
	hostPort：单一节点
	hostNetwork：共享宿主机网络

去除污点，使master节点可以调度pod
kubectl taint node vm1 node-role.kubernetes.io/master-

增加污点，使master节点不可以调度pod
kubectl taint node vm1 node-role.kubernetes.io/master=:NoSchedule

POD管理

    sidecar：边车，在一个pod中只有一个主容器，其他都是辅助容器，成为边车
	
	node network:与外部网络接口
	service network
	pod network

service的nodeport映射的端口是3000-32767之间的随机端口，但是如果从外部访问的时候不能直接访问一个随机端口，所以应该再在整个k8s集群外部设置一层lb即haproxy，设置成默认服务的端口。haproxy也是软件设置，与内部service的存在与否是联动的 cloud-controller-manager就是这样的一个组件，实现与k8s集群外部的组件进行联动的一个api

标签：
label、 label selector
kubectl label -h

initcontainers:初始化容器，运行完初始化容器，才能进行maincontainers的创建和运行

liveness：存活状态探测（有权利重启容器）
示例：(默认10s检测一次，默认检测三次，此示例重启6次之后pod状态失败)

apiVersion: v1
kind: Pod
metadata:
  name: liveness-pod
  labels:
    test: liveness-pod
spec:
  containers:
  - name: liveness-test
    image: busybox
    args:
    - /bin/sh
    - -c
    - touch /tmp/healthy;sleep 30;rm -rf /tmp/healthy;sleep 600
    livenessProbe:
      exec:
        command:
        - test
        - -e
        - /tmp/healthy

readiness：就绪状态探测（没有权利重启容器，探测不成功，继续探测）
示例：

apiVersion: v1
kind: Pod
metadata:
  name: readiness-pod
  labels:
    test: readiness-test
spec:
  containers:
  - name: readiness-test
    image: nginx:1.14-alpine
    args: ["/bin/sh","-c","while true;do rm -f /tmp/ready;sleep 30;touch /tmp/ready;sleep 300;done"]
    readinessProbe:
      exec:
        command: ["test","-e","/tmp/ready"]
      initialDelaySeconds: 5
      periodSeconds: 5

容器的重启策略：
always
onfailure
never

Pod Security
两个级别：
pods.spec.securityContext
pods.spec.containers.[].securityContext
capabilities

Pod resources:系统资源，内存、CPU
内存属于不可压缩性资源，一旦请求不到所必需的内存，就会oom，系统就会把进程干掉
一旦出现oom，两个原因：一个是系统资源少，一个是pod资源设置上限小
CPU属于可压缩性资源，一个进程请求不到资源，就会等着，等请求到资源为止

...
containers:
- name: xxx
  image: xxx
  resources:
    requests:               #下限
      memory: "128Mi"
      cpu: "200m"
    limits:                 #上限
      memory: "512Mi"
      cpu: "400m" 

Pod服务质量：根据pod对象的requests和limits属性
Guaranteed：每个容器都为CPU和内存设置了相同值得requests和limits属性
Burstable：至少有一个容器设置了CPU或内存的requests属性
BestEffort：未为任何一个容器设置requests或limits属性

Controller

通过control loop循环保证current status和spec status达到一致，不一致的话要通过makeChanges方法进行各种动作达到一致

类型

replication controller
replicaSet controller
deployment controller
daemonSet controller
statefulSet controller 有状态控制器
job controller

配置文件路径

master节点：/etc/kubernetes/manifests

应用程序可划分为多种类型：
守护进程型：
无状态
非系统级：deployment、replicaSet
系统级：daemonSet（每个节点只有一个该应用pod）
有状态：statefulSet
非守护进程型：
job、cronJob

示例：

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: busybox-rs
spec:
  replicas: 1
  selector:
    matchLabels:
      app: busybox-pod
  template:
    metadata:
      labels:
        app: busybox-pod
    spec:
      containers:
      - name: busybox
        image: busybox
        command: ["/bin/sh","-c","sleep 86400"]

滚动发布：deployment controller
deployment—>replicaSet—>pod
pod模板（template）必须改变，才会发生滚动更新

金丝雀发布：deployment contoller 发布一部分，引入一些不重要的流量，测试，然后再发布其他的
kubectl set image deployment deployName containerName=imageName && kubectl rollout pause deployment deployName
通过service导流量，把一部分不重要的流量导入新发布的应用中，然后观察。service只能把流量导入到新的应用或者是旧的应用，还要配合其他的产品来完成新旧应用的区分

deployment示例：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: deploy-nginx
spec:
  replicas: 3
  minReadySeconds: 10
  strategy:                      #滚动策略
    rollingUpdate:
      maxSurge: 1                #比起先的pod数，允许新创建pod的最大值      
      maxUnavailable: 1          #比起先的pod数，允许销毁pod的最大值
    type: RollingUpdate
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14-alpine
        ports:
        - containerPort: 80
          name: http
        readinessProbe:                #就绪检测
          periodSeconds: 1
          httpGet:
            path: /
            port: http

kubectl apply -f xxx.yaml --record #记录每一次的更新

kubectl set image deployment deployName containerName=imageName

kubectl rollout

DaemonSet

在一个node上只运行一个该相应pod
selector
template

示例：

apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: filebeat
spec:
  selector:
    matchLabels:
      app: filebeat
  template:
    metadata:
      labels:
        app: filebeat
      name: filebeat
    spec:
      containers:
      - name: filebeat
        image: docker.elastic.co/beats/filebeat:7.7.0
        env:
        - name: REDIS_HOST
          value: db.ikubernetes.io:6379
        - name: LOG_LEVEL
          value: info

Job

一次性作业任务，成功完成任务之后就会退出
串行作业
并行作业 parallelism
completion

CronJob

Service

service资源为动态管理的Pod对象添加一个有着固定访问入口的抽象层
service通过标签选择器关联至拥有相关标签的Pod对象
service后端可以是pod对象，也可以是非集群内对象
客户端向service进行请求，而非目标Pod对象

示例：

apiVersion: v1
kind: Service
metadata:
  name: svc-demo
spec:
  ports:
  - name: http
    port: 8080
    targetPort: 80
  selector:             #通过标签选择来对应后端的pod，此时pod必须打有标签
    app: nginx

将外部service引入集群内pod
type: externalName 此externalName注册在集群内的dns内，可供集群解析
集群内的service后端挂集群外的endpoint，此时不需要设置selector

headless 无头服务
解析service的name，是直接解析到pod的ip上

sessionAffinity：会话粘性

ipvs模块设置：（其实需要部署集群之前设置ipvs模块）
kubectl get cm -n kube-system
kubectl edit cm kube-proxy -n kube-system

如果集群内的kube-proxy没有自动加载，需要手动删除然后会自动running。

Ingress

ipvs,iptables: 4layer proxy
ingress: 7layer proxy http 把集群外部的流量引入到集群内部
client—>ingress controller—>pods

traefik:动态发现相关联pod

流控，ab

istio：服务网格，在金丝雀发布的时候，可以控制那些流量流入那些rs，甚至可以控制多少流量流入