一.资源编排

1.如何编写yaml文件

a.使用kubectl create命令生成yaml文件

[root@k8smaster ~]# kubectl create deployment web --image=nginx -o yaml --dry-run >my.yaml
W1118 14:35:35.036088    5186 helpers.go:535] --dry-run is deprecated and can be replaced with --dry-run=client.

b.使用get deploy导出yaml文件

[root@k8smaster ~]# kubectl get deploy nginx -o=yaml --export > my2.yaml
Flag --export has been deprecated, This flag is deprecated and will be removed in future.

二.Pod

1.概念

（1）最小部署单元（k8s不会直接处理容器，而是处理pod） （2）包含多个容器，一组容器的集合 （3）一个Pod中容器共享网络命名空间 （4）Pod是短暂的

2.Pod存在的意义

（1）创建容器使用docker，一个docker对应一个容器，一个容器有进程，一个容运行一个应用程序 （2）Pod是多进程设计，运行多个应用程序：

  • 一个Pod有多个容器，一个容器里面运行一个应用程序 （3）Pod存在为了亲密性应用
  • 两个应用之间的调用
  • 网络之间调用
  • 两个应用需要频繁调用

3.Pod的实现机制

（1）共享网络

  • 创建Pod首先会创建Pause根容器，ip mac port
  • 然后将后续创建的业务容器加入该容器
  • 让所有业务容器在同一个名称空间之中

（2）共享存储

  • 共享数据卷（volume）：持久化存储
  • Pod持久化数据：日志数据、业务数据
  • 引入数据卷概念，使用数据卷进行持久化存储

3.Pod镜像资源

（1）镜像拉取策略 （2）资源请求和限制

4.Pod重启策略

（1）重启策略

5.Pod健康检查

（1）常规容器检查

  • 不能检查出->Java堆内存溢出

（2）应用层面检查（K8S）

  • livenessProbe（存活检查）：如果检查失败，将杀死容器，根据Pod的restartPolicy来操作
  • readinessProbe（就绪检查）：如果检查失败，Kubenetes会把Pod从Service endpoints中剔除

6.Pod调度策略

（1）查看Pod

[root@k8smaster ~]#  kubectl get pods
NAME                    READY   STATUS    RESTARTS   AGE
nginx-f89759699-9vphp   1/1     Running   0          14h
[root@k8smaster ~]# kubectl get pods -o wide
NAME                    READY   STATUS    RESTARTS   AGE   IP           NODE       NOMINATED NODE   READINESS GATES
nginx-f89759699-9vphp   1/1     Running   0          14h   10.244.1.4   k8snode1   <none>           <none>

（2）创建Pod的流程 （3）Pod调度

  • 影响调度的属性
  • Pod资源限制，对Pod调度产生影响
  • 节点选择器标签nodeSelector，影响调度
nodeSelector： env_role: dev //分组名 
#给节点上标签 
[root@k8smaster ~]# kubectl label node k8snode1 env_role=dev node/k8snode1 labeled 
#查看节点标签信息 
[root@k8smaster ~]# kubectl get nodes k8snode1 --show-labels NAME STATUS ROLES AGE VERSION LABELS k8snode1 Ready <none> 15h v1.18.0 beta.kubernetes.io/arch=amd64,beta.kubernetes.io/os=linux,env_role=dev,kubernetes.io/arch=amd64,kubernetes.io/hostname=k8snode1,kubernetes.io/os=linux
  • 节点亲和性nodeAffinity：和nodeSeletctor相似
    • 硬亲和性
    • 约束条件必须满足：nodeSelector
    • 软亲和性
  • 污点和污点容忍
    • 相反于nodeSelector和nodeAffinity
    • Taint污点：节点不做普通的分配调度，是节点属性
    • 场景：专用节点、配置特定硬件节点、基于Taint驱逐节点
#查看污点节点情况 
[root@k8smaster ~]# kubectl describe node k8smaster | grep Taint Taints: node-role.kubernetes.io/master:NoSchedule #NodeSchedule:一定不被调度 
#ProferNoschdule:尽量不被调度 
#NoExecute:不会调度，并且还会驱逐Node已有Pod 
#添加污点 
kubectl taint node k8snode1 env_role=yes:ProferNoSchdule 
理解：添加污点后，服务按照程度不会调度到改节点上，例如master一定不会被调度 
#删除污点 kubectl taint node k8snode1 env_role:NoSchedule-
  • 污点容忍

三、Controller

1.什么是Controller

  • 在集群上管理和运行容器的对象

2.Pod和Controller关系

  • 通过Controller实现与应用的运维：比如伸缩，滚动升级
  • 两者通过label标签建立关系

3.Deployment控制器应用场景

  • 应用场景
  • 部署无状态应用
  • 管理Pod和RelicaSet
  • 部署，滚动升级等功能
  • web服务，微服务

4.yaml文件字段说明

5.Deployment控制器部署应用

  • 无状态应用
  • 认为Pod都是一样的
  • 没有顺序要求
  • 不用考虑在哪个node上运行
  • 有状态应用
  • 上面的因素都要考虑到
  • 每个pod都是独立的，保持pod启动顺序和唯一性
  • 唯一的网络标识符来确定，持久存储
  • 有序，比如mysql主从
  • 部署无状态应用
#导出命令为yml文件
[root@k8smaster ~]# kubectl create deployment web --image=nginx --dry-run -o yaml > web.yml
W1118 16:04:44.589583   27094 helpers.go:535] --dry-run is deprecated and can be replaced with --dry-run=client.

#创建
[root@k8smaster ~]# kubectl apply -f web.yaml
deployment.apps/web created

#对外发布，暴露端口
#导出命令
[root@k8smaster ~]# kubectl expose deployment web --port=80 --type=NodePort --target-port=80 --name=web1 -o yaml > web1.yaml
#发布
[root@k8smaster ~]# kubectl apply -f web1.yaml
Warning: kubectl apply should be used on resource created by either kubectl create --save-config or kubectl apply
service/web1 configured
  • 部署有状态应用
  • 无头service
    • ClusterIP：none
  • StatefulSet:
  • 查看pod：有三个Pod，每个都是唯一名称
  • deployment和statefueset区别
    • 根据主机名+按照一定规则生成域名
    • 唯一域名：主机名称.service名称.名称空间.svc.cluster.local

6.升级回滚

  • 设置镜像版本
  • 升级镜像版本
[root@k8smaster ~]# kubectl set image deployment web nginx=nginx:1.15
  deployment.apps/web image updated

通过创建副本，保证升级过程中服务不中断

  • 版本控制
#查看升级状态 
  [root@k8smaster ~]# kubectl rollout status deployment web
  deployment "web" successfully rolled out

  #查看历史版本
  [root@k8smaster ~]# kubectl rollout history deployment web
  deployment.apps/web 
  REVISION  CHANGE-CAUSE
  1         <none>
  2         <none>
  3         <none>
  #回滚到上一个版本
  [root@k8smaster ~]# kubectl rollout undo deployment web
  deployment.apps/web rolled back

  #回滚到指定版本
  [root@k8smaster ~]# kubectl rollout undo deployment web --to-revision=1
  deployment.apps/web rolled back
  [root@k8smaster ~]# kubectl rollout status deployment web
  Waiting for deployment "web" rollout to finish: 1 old replicas are pending termination...
  deployment "web" successfully rolled out

7.弹性伸缩

#控制副本数量
[root@k8smaster ~]# kubectl scale deployment web --replicas=3
deployment.apps/web scaled

四、Service

1.Service意义

  • 为了防止Pod失联（服务发现）类似注册中心
  • 负载均衡 定义一组Pod的访问策略

2.Pod和Service关系

  • 根据label和selector标签建立关联

3.常用的service类型

  • ClusterIP, NodePort, LoadBalancer, or ExternalName
  • ClusterIP：集群内部使用
  • NodePort：对外访问应用使用
  • LoadBalancer：对外访问应用使用，公有云

五、应用

1.部署守护进程（DaemonSet）

  • 在每个node上运行一个pod，新加入的pod也同样运行在一个node里面

2.任务

  • 一次性任务
  • 定时任务

3.集群安全机制

  • 访问k8s集群的时候，需要
  1. 认证
  2. 鉴权（授权）
  3. 准入控制
  • 进行访问的时候，过程中经过apiserver，做统一协调
  • 传输安全：对外不暴露8080端口，对外使用6443
  • 认证
  • 认证常用方式，
    • https证书基于ca证书
    • http tocken
    • http 基本认证，用户名+密码认证
  • 鉴权（授权）
  • 基于RBAC进行鉴权操作
    • 基于角色的访问控制
  • 基于角色访问控制
  • 准入控制
  • 准入控制器列表，如果列表没有请求内容，访问拒绝

六、Ingress

1.对外暴露端口

  • 使用Service里面的Nodeport暴露
  • NodePort缺陷
    • 在每个节点上都会起到端口，在访问时候通过任何节点ip+端口号实现访问
    • 意味着，每个端口只能使用一次，一个端口对应一个应用
    • 实际访问中都是域名访问，根据不同域名跳转到不同端口服务中

2.Ingress和Pod关系

  • pod和ingress通过service关联，ingress作为统一入口，由service关联一组pod

3.Ingress工作流程

4.部署Ingress

  • 部署Ingress Controller
  • 创建nginx应用，对外暴露端口
  • 创建Ingress规则