kubernetes入门

zoukankan html css js c++ java

kubernetes入门
简介
- Docker发布Docker Swarm，架构优秀，但是功能简单，不能完全符合市场需求
- Google发布Go语言开发的开源Kubernetes项目，参考Borg系统开发，技术成熟，功能强大，使用简单
- Kubernetes简称k8s，架构如下图所示：
组件介绍
- API-Server：整个集群的核心，基本上所有的组件都需要和API-Server进行交互，也是外界访问Kubernetes的唯一入口
- Etcd：键值对分布式数据库，集群中所有的重要信息都存储在其中
- Schedular：调度器，负责调度Pod到那个节点上运行
- Controller：控制器，主要是对Pod进行控制
- Kubelet：从节点上负责与主节点上的API-Server进行交互的组件，同时负责与本节点的容器进行通信
- Kube-Proxy：用来转发service中定义的服务，实现外部可以访问集群内的服务
- Flanner：一种覆盖网络，实现集群内Pod之间的通信
- DNS：域名解析服务(高版本默认安装)
- Dashboard：基于网页的Kubernetes用户界面，用于实时查看集群的内部状态
- Helm：服务安装工具，类似Centos上的yum，python中的pip，方便高效
- EFK：日志查看工具
控制器
- Replication Controller：用于控制副本的个数，是的副本个数始终等于期望的个数。
- Replication Set：是Replication Controller的升级版本，包含Replication Controller的全部功能，新增基于Label selector的集合操作。
- Deployment：新增组件，通过控制Replication Set的方式控制副本数，主要是新增升级和回滚功能。升级的大概流程：创建一个新的RS，控制老的RS杀死一个副本，控制新的RS创建一个副本，依次循环，直到所有的老副本都变成新副本，然后杀死老的RS。回滚也是相同的流程，可以把回滚理解成升级的目标版本是老版本。
- StatefulSet：主要是处理有状态服务，目前是Kubernetes的短板。无状态：如流水线上的工人可以随时离开一段时间，回来后可以继续无缝连接工作；有状态：部门开发经理离开一段之后，再回来工作可能就不能跟上节奏了，因为项目的状态在实时更新，对比服务，最明显的例子就是数据库服务。
- Daemon Set：保证每个节点上都运行一个Pod，主要适用于日志采集和性能监控服务
- Job：保证任务执行一次且成功结束，相比于手动执行任务，Job的优势是如果任务异常结束，会被重新执行，直到成功结束
- Corn Job：周期性定时运行任务
Flanner网络

Flannel实质上是一种“覆盖网络(overlay network)”，在现有的网络上实现另外一层网络，主要是将需要发送的报文通过UDP的方式封装，然后通过真实的网卡传输，在目的端解封得到传输的报文，最后根据传输的报文将报文发送给指定IP的Pod。需要注意的是：这里传输的数据是TCP/TCMP/UDP等格式的报文。宏观上理解是：在应用层上定义一种私有协议，实现多主机上的点对点传输，只不过这种私有协议是TCP/TCMP/UDP等。

处理流程：数据从源容器中发出后，经由所在主机的docker0虚拟网卡转发到flannel0虚拟网卡(桥接方式)，这是个P2P的虚拟网卡，flanneld服务监听在网卡的另外一端。Flannel通过Etcd服务维护了一张节点间的路由表，详细记录了各节点子网网段。源主机的flanneld服务将原本的数据内容UDP封装后根据自己的路由表投递给目的节点的flanneld服务，数据到达以后被解包，然后直接进入目的节点的flannel0虚拟网卡，然后被转发到目的主机的docker0虚拟网卡，最后就像本机容器通信一下的有docker0路由到达目标容器。flannel0虚拟网卡的作用就是UDP封装和解封，在容器层面感知不到，就像直接Socket通信一样。控制容器的的IP地址，是通过设置容器的启动参数--bip实现。

Pod
- Pod是Kubernetes中能够创建和部署的最小单元，一个Pod中可能包含一个或多个容器，属于同一个Pod的所有容器共享一个IP，且数据卷也是共享，彼此之间通过localhost就可以通信。Pod可以分为两种：自主式Pod和控制器管理的Pod。
- 所有的Pod在启动时会默认创建一个pasue的容器，然后里面的其他容器共享pause的网络协议栈，达到IP相同的目的
- Kubernetes为什么不将容器当做调度的最小单元？
  
  Pod需要和ApiServer进行通信，包括交互探测到的容器健康状态，如果直接将具体的容器当做调度单元管理，那么需要针对具体的容器类型进行开发，非常麻烦。启用pod之后，直接在Pod里面进行差异化开发，对ApiServer统一接口。基本思想就是增加一层，解决差异化。
  
  大多数时候，一个业务的建立需要多个容器联合完成，将彼此管理的多个容器一起调度更加合适
- Pod的状态
资源
- 空间名称级别
  
  工作负载型：Pod，RC，RS，Deployment，StatefulSet，DaemonSet，Job，CronJob
  
  服务发现型：Service，Ingress
  
  存储型：Volume，CSI（容器存储统一接口，标准）
  
  特殊型存储卷：ConfigMap（当配置中心使用的资源类型），Secret（保存敏感数据），DownwardAPI（外部信息输入给容器）
- 集群级别
  
  Namespace，Node，Role，ClusterRole，RoleBinding，ClusterRoleBinding
- 元数据型
  
  HPA，PodTemplate，LimitRange
  
  理解成有一定指标的东西
- Kubernetes中所有的内容都可以抽象为资源，资源实例化之后（理解为被执行），叫做对象
yaml格式

YAML语言的设计目标是方便人类读写。它实质上是一种通用的数据串行化格式。它的基本语法规则如下：
- 大小写敏感
- 使用缩进表示层级关系
- 缩进时不允许使用Tab键，只允许使用空格
- 缩进的空格数目不重要，只要相同层级的元素左侧对齐即可
- # 表示注释，从这个字符一直到行尾，都会被解析器忽略
YAML支持的数据结构有三种：
- 对象：键值对的集合，又称为映射（mapping）/ 哈希（hashes） / 字典（dictionary）
- 数组：一组按次序排列的值，又称为序列（sequence） / 列表（list）
- 纯量（scalars）：单个的、不可再分的值
对象：对象的一组键值对，使用冒号结构表示
animal: pets hash: { name: Steve, foo: bar }
数组：一组连词线开头的行，构成一个数组
animal： - Cat - Dog - Goldfish animal: [Cat, Dog]
纯量：纯量是最基本的、不可再分的值。以下数据类型都属于 JavaScript 的纯量：
- 字符串
- 布尔值
- 整数
- 浮点数
- Null
- 时间
- 日期
number: 12.30 isSet: true iso8601: 2001-12-14t21:59:43.10-05:00 date: 1976-07-31
字符串：字符串是最常见，也是最复杂的一种数据类型。
- 字符串默认不使用引号表示
- 如果字符串之中包含空格或特殊字符，需要放在引号之中
- 单引号和双引号都可以使用，双引号不会对特殊字符转义
- 单引号之中如果还有单引号，必须连续使用两个单引号转义
- 字符串可以写成多行，从第二行开始，必须有一个单空格缩进。换行符会被转为空格
- 多行字符串可以使用|保留换行符，也可以使用>折叠换行
- +表示保留文字块末尾的换行，-表示删除字符串末尾的换行
str: 这是一行字符串 str: '内容：字符串' str: 'labor''s day' this: | Foo Bar that: > Foo Bar #{ this: 'Foo Bar ', that: 'Foo Bar ' } str: 这是一段多行字符串 #{ str: '这是一段多行字符串' } s1: | Foo s2: |+ Foo s3: |- Foo #{ s1: 'Foo ', s2: 'Foo ', s3: 'Foo' }
yaml常用字段
apiVersion: v1 #必选，版本号，例如v1 kind: Pod #必选，Pod metadata: #必选，元数据 name: string #必选，Pod名称 namespace: string #必选，Pod所属的命名空间 labels: #自定义标签 - name: string #自定义标签名字 annotations: #自定义注释列表 - name: string spec: #必选，Pod中容器的详细定义 containers: #必选，Pod中容器列表 - name: string #必选，容器名称 image: string #必选，容器的镜像名称 imagePullPolicy: [Always | Never | IfNotPresent] #获取镜像的策略 #Alawys表示总是下载镜像 #IfnotPresent表示优先使用本地镜像，本地没有就下载镜像 #Nerver表示仅使用本地镜像 command: [string] #容器的启动命令列表，如不指定，使用打包时使用的启动命令 args: [string] #容器的启动命令参数列表 workingDir: string #容器的工作目录，进入容器的起始目录 volumeMounts: #挂载到容器内部的存储卷配置 - name: string #引用pod定义的共享存储卷的名称，需用volumes[]部分定义的的卷名 mountPath: string #存储卷在容器内mount的绝对路径，应少于512字符 readOnly: boolean #是否为只读模式 ports: #需要暴露的端口库号列表 - name: string #端口号名称 containerPort: int #容器需要监听的端口号 hostPort: int #容器所在主机需要监听的端口号，默认与Container相同 protocol: string #端口协议，支持TCP和UDP，默认TCP env: #容器运行前需设置的环境变量列表 - name: string #环境变量名称 value: string #环境变量的值 resources: #资源限制和请求的设置 limits: #资源限制的设置 cpu: string #Cpu的限制，单位为core数，将用于docker run --cpu-shares参数 memory: string #内存限制，单位可以为Mib/Gib，将用于docker run --memory参数 requests: #资源请求的设置 cpu: string #Cpu请求，容器启动的初始可用数量 memory: string #内存清楚，容器启动的初始可用数量 livenessProbe: #对Pod内个容器健康检查的设置，当探测无响应几次后将自动重启该容器 #检查方法有exec、httpGet和tcpSocket，对一个容器只需设置其中一种方法即可 exec: #对Pod容器内检查方式设置为exec方式 command: [string] #exec方式需要制定的命令或脚本 httpGet: #对Pod内个容器健康检查方法设置为HttpGet，需要制定Path、port path: string port: number host: string scheme: string HttpHeaders: - name: string value: string tcpSocket: #对Pod内个容器健康检查方式设置为tcpSocket方式 port: number initialDelaySeconds: 0 #容器启动完成后首次探测的时间，单位为秒 timeoutSeconds: 0 #对容器健康检查探测等待响应的超时时间，单位秒，默认1秒 periodSeconds: 0 #对容器监控检查的定期探测时间设置，单位秒，默认10秒一次 successThreshold: 0 failureThreshold: 0 securityContext: privileged:false restartPolicy: [Always | Never | OnFailure] #Pod的重启策略 #Always表示一旦不管以何种方式终止运行，kubelet都将重启 #OnFailure表示只有Pod以非0退出码退出才重启 #Nerver表示不再重启该Pod nodeSelector: obeject #设置NodeSelector表示将该Pod调度到包含这个label的node上 #以key：value的格式指定 imagePullSecrets: #Pull镜像时使用的secret名称，以key：secretkey格式指定 - name: string hostNetwork:false #是否使用主机网络模式，默认为false，如果设置为true，表示使用宿主机网络 volumes: #在该pod上定义共享存储卷列表 - name: string #共享存储卷名称（volumes类型有很多种） emptyDir: {} #类型为emtyDir的存储卷，与Pod同生命周期的一个临时目录。为空值 hostPath: string #类型为hostPath的存储卷，表示挂载Pod所在宿主机的目录 path: string #Pod所在宿主机的目录，将被用于同期中mount的目录 secret: #类型为secret的存储卷，挂载集群与定义的secre对象到容器内部 scretname: string items: - key: string path: string configMap: #类型为configMap的存储卷，挂载预定义的configMap对象到容器内部 name: string items: - key: string # 一个简单的Pod定义 apiVersion: v1 kind: Pod metadata: name: my-pod labels: name: my-pod version: v1 spec: containers: - name: one image: nginx ports: - containerPort: 80 - name: two image: jcdemo/flaskapp ports: - containerPort: 5000　
Pod生命周期
1. 启动pause容器，每个Pod默认具有，主要是初始化网络和数据卷
2. pause串行启动初始化容器（initC），只到所有的初始化容器都成功执行
3. pause并行启动主容器（mainC），启动开始钩子（post start），启动探针（liveness probe，readness probe）
4. 在主容器结束之前，调用结束钩子（pre stop）
为什么分离出初始化容器，而不将所有的功能都封装在主容器中？
- 容器功能越单一越好，越适合调度
- 权限管理，更加安全。容器只具备需要访问的安全，其他都不应该具有
- 执行共性操作，如果一个Pod里面包含多个容器，都需要使用同一份代码，那么可以在初始容器里面将代码下载好，然后主容器共用
探针和钩子
- livenessProbe：探测容器是否活着
  
  httpGet：http请求方式，如果返回的HTTP状态码在200和399之间，则认为程序正常，否则异常
  
  exec：命令方式，在用户容器内执行一次命令，如果命令执行的退出码为0，则认为程序正常，否则异常
  
  tcpSocket：访问端口方式，如果能够建立成功则认为程序正常，否则异常
- readnessProbe：探测容器是否准备就绪
  
  httpGet：http请求方式，如果返回的HTTP状态码在200和399之间，则认为程序正常，否则异常
  
  exec：命令方式，在用户容器内执行一次命令，如果命令执行的退出码为0，则认为程序正常，否则异常
  
  tcpSocket：访问端口方式，如果能够建立成功则认为程序正常，否则异常
- lifecycle
  
  postStart 启动后执行
  
  preStop 终止前执行
  
  执行方式和探针相同
- 例子
apiVersion: v1 kind: Pod metadata: name: readiness-httpget-pod namespace: default labels: name: myapp spec: containers: - name: readiness-httpget image: ikubernetes/myapp:v1 ports: - name: http containerPort: 80 imagePullPolicy: IfNotPresent readinessProbe: httpGet: port: http path: /index.html initialDelaySeconds: 1 periodSeconds: 3
--- apiVersion: v1 kind: Pod metadata: name: liveness-httpget-pod namespace: default labels: name: myapp spec: containers: - name: livess-httpget image: ikubernetes/myapp:v1 ports: - name: http containerPort: 80 imagePullPolicy: IfNotPresent livenessProbe: httpGet: port: http path: /index.html initialDelaySeconds: 1 periodSeconds: 3
--- apiVersion: v1 kind: Pod metadata: name: lifecycle-poststart namespace: default labels: name: myapp tier: appfront spec: containers: - name: lifecycle-poststart-pod image: nginx imagePullPolicy: IfNotPresent lifecycle: postStart: exec: command: ["/bin/sh","-c","echo Home+Page >> /usr/share/message"] preStop: exec: command: ["/usr/sbin/nginx","-s","quit"]
最简单的Pod例子
apiVersion: v1 kind: Pod metadata: name: my-pod labels: name: my-pod spec: containers: - name: busybox image: busybox:latest
Deployment的升级和回退
- 升级：如更新image：kubectl set image mydeploy mynginx=docker.io/nginx:1.15
- --record=true：记录每次操作的命令，并与history查看
- 回退：kubectl rollout history deployment mydeploy
apiVersion: v1 kind: Deployment metadata: name: my-deploy namespace: default spec: replicas: 2 selector: matchLabels: app: myapp template: metadata: labels: app: myapp spec: containers: - name: busybox image: busybox:latest
DaemonSet升级策略
- 通过.spec.updateStrategy.type指定
- OnDelete: 该策略表示当更新了DaemonSet的模板后，只有手动删除旧的DaemonSet Pod才会创建新的DaemonSet Pod
- RollingUpdate：该策略表示当更新DaemonSet模板后会自动删除旧的DaemonSet Pod并创建新的DaemonSetPod
- 要使用DaemonSet的滚动升级，需要 .spec.updateStrategy.type设置为RollingUpdate
apiVersion: v1 kind: DaemonSet metadata: name: my-DaemonSet spec: selector: matchLabels: name: myapp template: metadata: labels: name: myappt spec: containers: - name: busybox image: busybox:latest
Job
- spec.template格式同Pod
- RestartPolicy仅支持Never或OnFailure
- 单个Pod时，默认Pod成功运行后Job即结束
apiVersion: batch/v1 kind: Job metadata: name: pi spec: backoffLimit: 6 # 最多失败6次 completions: 1 # 有一个Job成功运行 parallelism: 1 # 一次性运行pod的个数 template: metadata: name: pi spec: containers: - name: pi image: perl command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"] restartPolicy: Never
CornJob
- CornJob通过控制JJob实现功能
- schedule格式：(与crontab格式相同)
  
  *****：从左到右依次是分钟，小时，每个月的第几天，月，星期几
  
  每15分钟：0，15，30，45****
  
  每隔30分钟运行一次，但仅在每月的第一天运行：0,30*1**
  
  每天3-5,17-20每隔30分钟：*/30 [3-5],[17-20] * * *
apiVersion: batch/v1beta1 kind: CronJob metadata: name: hello spec: schedule: "*/1 * * * *" jobTemplate: spec: template: spec: containers: - name: busybox image: busybox:latest args: - /bin/sh - -c - date; echo Hello from the Kubernetes cluster restartPolicy: OnFailure
注意：Job和CornJob没有selector，deployment，DaemonSet有selector

Service

Service类型
- ClusterIP：默认方式，仅集群内部可以访问
- NodePort：service的port映射到集群内每个节点的一个相同端口，外部使用节点IP和端口就可以访问
- LoadBalancer：使用外部云服务上的负载均衡服务，要交钱。也可以自己搭建一个负载均衡，如下如
- ExternalName：将service接收到的请求转发到另外的域名（有可能是在集群内部，有可能是在集群外部）
- 无头服务：也是一种service，只有service名称，没有ClusterIP，可以通过访问名称的方式访问后端Pod，但是没有负载均衡的功能。名称类似：my-service.default.svc.cluster.local.
- 一个简单的service例子
apiVersion: v1 kind: Service metadata: name: my-nginx labels: app: nginx spec: type: ClusterIP ports: - port: 80 targetPort: 80 selector: app: my-pod
Proxy模式
- userspace模式，缺点kube-proxy的压力很大，已经放弃
- iptables模式：使用iptables进行路由转发
- ipvs模式：架构和iptables一样，不同的是ipvs的转发效率更高。需要注意的是：使用ipvs要事先进行配置。否则默认使用iptables模式
StatefulSet
- StatefulSet是deployment的变种，具有deployment的基本属性，如保存Pod的数量
- StatefulSet是Kubernetes提供的管理有状态应用的负载管理控制器API。在Pods管理的基础上，保证Pods的顺序和一致性。与Deployment一样，StatefulSet也是使用容器的Spec来创建Pod，与之不同StatefulSet创建的Pods在生命周期中会保持持久的标记
- 特点：
  
  具有固定的网络标记（主机名），是不是通过Pod的IP，使用的是无头服务
  
  具有持久化存储，使用pvc实现
  
  需要按顺序部署和扩展，第一个Pod启动完成后，才能启动第二个；如果序号为2的Pod死亡，会重新起一个Pod，名称和原来一样(无头服务通过名称解析IP，保证新起的Pod是第二个Pod)
  
  需要按顺序终止及删除，，删除的顺序和创建时相反，删除时也是上一个Pod删除成功后，才会删除下一个Pod
  
  需要按顺序滚动更新，更新时也是上一个Pod更新成功后，才会更新下一个Pod
- demo
apiVersion: v1 kind: Service metadata: name: nginx labels: app: nginx spec: ports: - port: 80 name: web clusterIP: None # 无头服务 selector: app: nginx --- apiVersion: apps/v1 kind: StatefulSet metadata: name: web spec: serviceName: "nginx" replicas: 2 selector: matchLabels: app: nginx template: metadata: labels: app: nginx spec: containers: - name: nginx image: docker.io/nginx ports: - containerPort: 80 name: web volumeMounts: - name: www mountPath: /usr/share/nginx/html volumeClaimTemplates: - metadata: name: www spec: accessModes: ["ReadWriteOnce"] volumeMode: Filesystem resources: requests: storage: 50Mi storageClassName: local-storage
Ingress

Ingress的优势
- service提供的是4层代理，Ingress提供的是7层代理（根据域名代理）
- Ingress对外提供统一的IP和端口，减少对外暴露的端口
- Ingess提供负载均衡
Ingress的大致流程
- 创建一个Ingress控制器，可以使用nginx搭建
- 创建Ingress
- Ingress控制器会实时监测Ingrss，将Ingress的配置自动添加到Ingress控制器(nginx的配置文件)
Ingress流程图

demo（http）
- 搭建nginx-ingress
# 直接到官网查看https://kubernetes.github.io/ingress-nginx/ kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/controller-0.31.1/deploy/static/provider/baremetal/deploy.yaml
- 搭建私有service
apiVersion: v1 kind: Service metadata: name: test-ingress namespace: default spec: ports: - port: 80 protocol: TCP targetPort: 80 selector: app: test-ingress --- apiVersion: apps/v1beta1 kind: Deployment metadata: name: test-ingress spec: replicas: 1 template: metadata: labels: app: test-ingress spec: containers: - image: nginx:latest imagePullPolicy: IfNotPresent name: test-nginx ports: - containerPort: 80
- 创建ingress，关联nginx-ingress与service
apiVersion: extensions/v1beta1 kind: Ingress metadata: name: test-ingress namespace: default annotations: kubernetes.io/ingress.class: "nginx" spec: rules: - host: feiutest.cn http: paths: - path: backend: serviceName: test-ingress servicePort: 80
- 测试：使用本地的host文件进行域名解析，然后通过域名访问
demo（https）
- 制作自签证书，生成tls.crt ，tls.key文件
openssl genrsa -out tls.key 2048 openssl req -new -x509 -key tls.key -out tls.crt -subj /C=CN/ST=Guangdong/L=Guangzhou/O=devops/CN=feiutest.cn
- 创建secret
#创建 kubectl create secret tls nginx-test --cert=tls.crt --key=tls.key #查看 kubectl get secret
- 修改ingress
apiVersion: extensions/v1beta1 kind: Ingress metadata: name: test-ingress namespace: default annotations: kubernetes.io/ingress.class: "nginx" spec: rules: - host: feiutest.cn http: paths: - path: backend: serviceName: test-ingress servicePort: 80 tls: - hosts: - feiutest.cn secretName: nginx-test
- 测试：使用https访问，注意端口号
ConfigMap

创建ConfigMap的方式：
- 在命令行中指定configmap参数创建，--from-literal
- 在命令行中将一个配置文件创建为一个ConfigMap--from-file=<文件>
- 在命令行中将一个目录下的所有配置文件创建为一个ConfigMap，--from-file=<目录>，和指定文件的创建方式相同
- 写好标准的configmap的yaml文件，然后kubectl create -f创建
- demo
kubectl create configmap test-config1 --from-literal = db.host = 10.5.10.116 --from-listeral = db.port = '3306' # key: db.host Value: 10.5.10.116 # key: db.port value: 3306 cat app.properties property.1 = value-1 property.2 = value-2 property.3 = value-3 kubectl create configmap test-config2 --from-file = ./app.properties # key: property.1 Value: value-1 # key: property.2 value: value-2 # key: property.3 Value: value-3 # configs 目录下的config-1和config-2内容如下 # key1 =value1 ############### # key2 =value2 kubectl create configmap test-config3 --from-file = ./configs # key: key1 value: value1 # key: key2 value: value2 cat my-configmap.yaml apiVersion: v1 kind: ConfigMap metadata: name: my-configmap namespace: default data: special.how: very special.type: charm kubectl create -f my-configmap.yaml # key: special.how Value: very # key: special.type value: charm
使用ConfigMap的方式
- 通过环境变量的方式，直接传递给pod
- 通过环境变量的方式，在yaml文件中通过命令使用环境变量，本质上就是通过环境变量的方式
- 作为volume的方式挂载到pod内，key就是文件名，value就是文件里面的内容，一个key一个文件
apiVersion: v1 kind: ConfigMap metadata: name: my-configmap namespace: default data: type: INFO --- apiVersion: v1 kind: Pod metadata: name: my-pod spec: containers: - name: busybox image: busybox:latest command: [ "/bin/sh", "-c", "env" ] env: - name: SPECIAL_LEVEL_KEY valueFrom: configMapKeyRef: name: my-configmap key: type restartPolicy: Never # 环境变量中会有SPECIAL_LEVEL_KEY=INFO
apiVersion: v1 kind: ConfigMap metadata: name: my-configmap namespace: default data: type: INFO --- apiVersion: v1 kind: Pod metadata: name: my-pod spec: containers: - name: busybox image: busybox:latest command: [ "/bin/sh", "-c", "echo ${SPECIAL_LEVEL_KEY}" ] env: - name: SPECIAL_LEVEL_KEY valueFrom: configMapKeyRef: name: my-configmap key: type restartPolicy: Never # 打印 INFO
apiVersion: v1 kind: ConfigMap metadata: name: my-configmap namespace: default data: type: INFO --- apiVersion: v1 kind: Pod metadata: name: my-pod spec: containers: - name: busybox image: busybox:latest command: [ "/bin/sh", "-c", "cat /etc/config/type" ] volumeMounts: - name: config-volume mountPath: /etc/config volumes: - name: config-volume configMap: name: my-configmap restartPolicy: Never # 容器的/etc/config/type文件里面的内容是INFO
Secret

Secret和ConfigMap的对比
- Secret和ConfigMap的总体思想类似，都是存储信息到Etcd，不同的是Secret存储的是密文。
- Secret和ConfigMap都可以通过环境变量和Volume的方式使用
- Secret的特点
  
  Secret可以被ServerAccount关联(使用)
  
  Secret可以存储register的鉴权信息，用在ImagePullSecret参数中，用于拉取私有仓库的镜像
  
  Secret支持Base64加密
  
  Secret分为kubernetes.io/Service Account，kubernetes.io/dockerconfigjson，Opaque三种类型,Configmap不区分类型
Secret的类型
- Opaque：base64编码格式的Secret，用来存储密码、密钥等。注意：value必须是base64加密
# 环境变量方式引用 apiVersion: extensions/v1beta1 kind: Deployment metadata: name: wordpress-deployment spec: replicas: 2 template: metadata: labels: app: wordpress spec: containers: - name: "wordpress" image: "wordpress" ports: - containerPort: 80 env: - name: WORDPRESS_DB_USER valueFrom: secretKeyRef: name: mysecret key: username - name: WORDPRESS_DB_PASSWORD valueFrom: secretKeyRef: name: mysecret key: password　　
# volume的方式引用 apiVersion: v1 kind: Pod metadata: labels: name: db name: db spec: volumes: - name: secrets secret: secretName: mysecret containers: - image: gcr.io/my_project_id/pg:v1 name: db volumeMounts: - name: secrets mountPath: "/etc/secrets" readOnly: true ports: - name: cp containerPort: 5432 hostPort: 5432
- kubernetes.io/dockerconfigjson：创建用于docker registry认证的secret，主要是用于从私有仓库拉取镜像
kubectl create secret docker-registry myregistrykey --docker-server = DOCKER_REGISTRY_SERVER --docker-username = DOCKER_USER --docker-password = DOCKER_PASSWORD --docker-email = DOCKER_EMAIL　
# pod中是使用registry信息 apiVersion: v1 kind: Pod metadata: name: foo spec: containers: - name: foo image: app:v1 imagePullSecrets: - name: myregistrykey
- kubernetes.io/service-account-token：被serviceaccount引用，serviceaccout创建时Kubernetes会默认创建对应的secret。Pod如果使用了serviceaccount，对应的secret会自动挂载到Pod的/run/secrets/kubernetes.io/serviceaccount目录中
Volume
- Vloume是Pod中能够被多个容器共享的磁盘目录
- 主要用于持久化和同一个pod里面多个容器之间的目录文件共享
- 分类很多：
  
  emptydir：在Pod创建时被创建，初始化为空，同一个Pod里面的同期都可以读写这个路径，当Pod死亡时，emptyDir也被删除，且永久消失
  
  hostPath：将node上的路径挂载到Pod中，Pod死亡后，路径里面的文件不会消失
- demo
apiVersion: v1 kind: Pod metadata: name: test-pd spec: containers: - image: k8s.gcr.io/test-webserver name: test-container volumeMounts: - mountPath: /cache name: cache-volume volumes: - name: cache-volume emptyDir: {} apiVersion: v1 kind: Pod metadata: name: test-pd spec: containers: - image: k8s.gcr.io/test-webserver name: test-container volumeMounts: # directory location on conainer - mountPath: /test-pd name: test-volume volumes: - name: test-volume hostPath: # directory location on host path: /data # this field is optional type: Directory
PV/PVC
- PV（PersistentVolume）：是集群中由管理员配置的一段网络存储。它是集群中的资源，就像节点是集群资源一样。PV的生命周期不受Pod影响，独立存在。主要的作用是适配后端所有的网络存储，对外提供统一接口。
- PVC（PersistentVolumeClaim）：是由用户进行存储的请求，类似 Pod消耗节点资源，PVC消耗PV资源。
- PV和PVC一一绑定，PVC匹配满足条件的最小容量PV
- PV状态：
  
  Available – 资源尚未被claim使用
  
  Bound – 卷已经被绑定到claim了
  
  Released – claim被删除，卷处于释放状态，但未被集群回收。
  
  Failed – 卷自动回收失败
- demo(nfs服务以安装且正常运行)
apiVersion: v1 kind: PersistentVolume metadata: name: pv001 labels: name: pv001 spec: nfs: path: /data/volumes/v1 server: nfs accessModes: ["ReadWriteMany"] capacity: storage: 2Gi --- apiVersion: v1 kind: PersistentVolume metadata: name: pv002 labels: name: pv002 spec: nfs: path: /data/volumes/v2 server: nfs accessModes: ["ReadWriteMany"] capacity: storage: 5Gi # 后端存储是nfs类型
apiVersion: v1 kind: PersistentVolumeClaim metadata: name: mypvc namespace: default spec: accessModes: ["ReadWriteMany"] resources: requests: storage: 4Gi # mypvc会绑定到pv002 apiVersion: v1 kind: Pod metadata: name: test-pod-pv-pvc namespace: default spec: volumes: - name: html persistentVolumeClaim: claimName: mypvc containers: - name: myapp image: ikubernetes/myapp:v1 volumeMounts: - name: html mountPath: /usr/share/nginx/html/ # 最后/data/volumes/v2会被挂在到容器mapp中的/usr/share/nginx/html/目录
节点调度
- scheduler进行调度主要分为两步：节点筛选和节点打分优先
- 节点筛选：遍历所有节点，选择满足条件的节点，解决的是“能不能”的问题
- 节点打分优先：遍历筛选后的节点，按照优先级打分，选择分数最高的节点。解决的是“那个更合适”的问题
- 调度的简单过程如下所示
- 节点筛选的规则
  
  NoVolumeZoneConflict：检查给定的zone限制前提下，检查如果在此主机上部署Pod是否存在卷冲突
  
  PodFitsResources：检查节点是否有足够资源（例如 CPU、内存与GPU等）满足一个Pod的运行需求
  
  PodFitsHostPorts：检查Pod容器所需的HostPort是否已被节点上其它容器或服务占用
  
  HostName：检查节点是否满足PodSpec的NodeName字段中指定节点主机名，不满足节点的全部会被过滤掉
  
  MatchNodeSelector：检查节点标签（label）是否匹配Pod的nodeSelector属性要求
  
  PodToleratesNodeTaints : 根据 taints 和 toleration 的关系判断Pod是否可以调度到节点上，Pod是否满足节点容忍的一些条件
  
  MatchInterPodAffinity : 节点亲和性筛选
  
  GeneralPredicates：包含一些基本的筛选规则
- 节点打分优先
  
  LeastRequestedPriority：节点的优先级由节点空闲资源与节点总容量的比值，即由（总容量-节点上Pod的容量总和-新Pod的容量）/总容量）来决定
  
  BalancedResourceAllocation：CPU和内存使用率越接近的节点权重越高，该策略不能单独使用，必须和LeastRequestedPriority组合使用，尽量选择在部署Pod后各项资源更均衡的机器
  
  InterPodAffinityPriority：通过迭代 weightedPodAffinityTerm 的元素计算和，并且如果对该节点满足相应的PodAffinityTerm，则将 “weight” 加到和中，具有最高和的节点是最优选的
  
  SelectorSpreadPriority：为了更好的容灾，对同属于一个service、replication controller或者replica的多个Pod副本，尽量调度到多个不同的节点上
  
  NodeAffinityPriority：节点亲和性机制
  
  NodePreferAvoidPodsPriority（权重1W）
  
  TaintTolerationPriority : 使用 Pod 中 tolerationList 与节点 Taint 进行匹配，配对成功的项越多，则得分越低
亲和性
- 亲和性是Pod靠近节点
- 节点亲和性：Pod优先调度到具有亲和性的节点上运行
apiVersion: v1 kind: Pod metadata: name: nginx labels: env: test spec: containers: - name: nginx image: nginx imagePullPolicy: IfNotPresent nodeSelector: # 选择具有disktype: ssd标签的节点 disktype: ssd # 给节点添加label # kubectl node label <node-name> <label-key>=<label-value> # 查看节点label # kubectl get nodes --show-labels # 删除节点label # kubectl label node <node-name> label-key-
apiVersion: v1 kind: Pod metadata: name: with-node-affinity spec: affinity: nodeAffinity: # 硬条件：节点必须包含kubernetes.io/e2e-az-name=e2e-az1的label才符合条件 requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/e2e-az-name operator: In values: - e2e-az1 # 软条件：节点尽量包含another-node-label-key=another-node-label-value的label， # 不包含也可以调度 preferredDuringSchedulingIgnoredDuringExecution: - weight: 1 preference: matchExpressions: - key: another-node-label-key operator: In values: - another-node-label-value containers: - name: with-node-affinity image: k8s.gcr.io/pause:2.0
- Pod亲和性：Pod之间的相互靠近和排斥
apiVersion: apps/v1beta1 kind: Deployment metadata: name: affinity labels: app: affinity spec: replicas: 3 revisionHistoryLimit: 15 template: metadata: labels: app: affinity role: test spec: containers: - name: nginx image: nginx:1.7.9 ports: - containerPort: 80 name: nginxweb affinity: podAffinity: requiredDuringSchedulingIgnoredDuringExecution: # 硬策略 - labelSelector: matchExpressions: - key: app operator: In values: - busybox-pod topologyKey: kubernetes.io/hostname # 上面这个例子中的pod需要调度到某个指定的主机上，且这个节点上运行了这样的pod：这个pod有一个 # app=busybox-pod的label
污点和容忍
- 污点和容忍是将Pod驱离节点，与亲和性相反
- 打上污点的节点，如果Pod没有容忍这个污点的能力，那么Pod就不会被调度到这个节点上；只有具备容忍这个污点能力的Pod才会被调度到这个节点上
- master节点上默认具有node-role.kubernetes.io/master:NoSchedule污点，所以Pod默认不会调度到master上
- 增加污点，删除污点，查看污点
# 查看节点具有的污点 kubectl describe node nodeName # 删除节点的污点 kubectl taint nodes nodeName key=value:NoSchedule # 删除节点的污点 kubectl taint nodes nodeName key-
- 污点驱离Pod的方式
  
  NoSchedule：不要调度到这个节点上
  
  PreferNoSchedule：尽量不调度到污点节点上
  
  NoExecute：不要调度到这个节点上，且会立即驱离已经运行在这个节点上的Pod
- 污点和容忍的匹配规则
  
  对tolerations属性的写法，其中pod的 key、value、effect 与Nod 的Taint设置需保持一致
  
  如果operator的值是Exists则value属性可省略
  
  如果operator的值是Equa，则表示其key与value之间的关系是equal(等于)
  
  如果不指定 operator 属性，则默认值为 Equal
- demo
apiVersion: apps/v1beta1 kind: Deployment metadata: name: taint labels: app: taint spec: replicas: 3 revisionHistoryLimit: 10 template: metadata: labels: app: taint spec: containers: - name: nginx image: nginx:1.7.9 ports: - name: http containerPort: 80 tolerations: - key: "node-role.kubernetes.io/master" operator: "Exists" effect: "NoSchedule" # 该Pod可以被调度到matser上
接入管理---前言

API Server作为Kubernetes网关，是访问和管理资源对象的唯一入口，其各种集群组件访问资源都需要经过网关才能进行正常访问和管理。每一次的访问请求都需要进行合法性的检验，其中包括认证，授权以及准入等，需要通过一系列验证之后，才能访问或者存储数据到etcd当中。如下图所示。

接入管理---认证
- 认证的主要作用是识别需要接入的对端身份，也就是解决“你是谁”的问题
- ControllerManager、Scheduler与ApiServer进行通信，直接走127.0.0.1进行通信，因为都在同一台服务器上
- kubelet和kube-peoxy与ApiServer进行通信，需要双向验证
- Pod与ApiServer进行通信，通过ServiceAccount进行通信。当创建Pod的时候，如果没有指定一个service account，系统会自动在与该Pod相同的namespace下为其指派一个default service account。
接入管理---鉴权
- 鉴权的主要作用是识别接入对端的权限，也就是解决“你能干什么”的问题
- kubernetes中鉴权使用的是RBAC（Role-Based Access Control），基于角色的访问控制，通过自定义角色并将角色和特定的 user，group，serviceaccounts 关联起来已达到权限控制的目的。
- Role：角色，它其实是一组规则，定义了一组对 Kubernetes API 对象的操作权限
- Subject：被作用者，包括 user，group，serviceaccounts，通俗来讲就是认证机制中所识别的用户
- RoleBinding：定义了“被作用者”和“角色”的绑定关系，也就是将用户以及操作权限进行绑定
- ClusterRole：集群角色，可以包含多个namespace
- ClusterRoleBinding：一次绑定多个namespace
- ClusterRole既可以被ClusterRoleBinding绑定，也可以被RoleBinding绑定，灵活处理即可
接入管理---准入控制

准入控制是请求的最后一个步骤，准入控制有许多内置的模块，可以作用于对象的 “CREATE”、“UPDATE”、“DELETE”、“CONNECT” 四个阶段。在这一过程中，如果任一准入控制模块拒绝，那么请求立刻被拒绝。一旦请求通过所有的准入控制器后就会写入对象存储中。准入控制的配置是有序的，不同的顺序会影响 Kubernetes 的性能，建议使用官方的配置。

Helm3安装和使用
- 安装
# 1. 下载 wget https://github.com/helm/helm/releases # 2. 解压 tar -zxvf helm-v3.0.0-linux-amd64.tgz # 3. 解压后的目录中找到二进制文件，然后将其移至所需的目标位置 mv linux-amd64/helm /usr/local/bin/helm # 4. 验证 helm help
- 自定义chart
# 创建文件和目录 # test/Chart.yaml test/values.yaml /test/templates/nginx.yaml # cat test/Chart.yaml apiVersion: v1 # 当前helm api版本，不需要修改 appVersion: 1.0.0 # 此处为你应用程序的版本号 [*] description: Chart for the nginx server # 介绍此chart是干嘛的，按需求修改 name: example-chart # 模板名，对应目录名 [*] version: 1.0.0 # 此chart版本号 [*] maintainers: # 维护人员列表 [*] - email: xxx name: yyy # cat test/values.yaml version: "1.0" # cat /test/templates/nginx.yaml apiVersion: v1 kind: Pod metadata: name: nginx labels: name: myapp spec: containers: - name: nginx image: nginx:{{.Values.version}} # 引用value中的配置 ports: - name: http containerPort: 80 imagePullPolicy: IfNotPresent
资源限制
- 资源限制主要是限制CPU和内存
- pod级别：在Pod级别对资源进行限制
- 名称空间级别：在名称空间级别对资源进行限制
日志查看EFK
- kubernetes中日志管理系统，主要是收集、存储、查看kubernetes中所有节点的所有日志
- ELK也是日志管理系统，但是ELK很“重”，EFK是ELK的变种，但是很“轻”
- EFK不是一个软件，而是一套解决方案，并且都是开源软件，之间互相配合使用，完美衔接，高效的满足了很多场合的应用，是目前主流的一种日志系统。EFK是三个开源软件的缩写，分别表示：Elasticsearch , FileBeat, Kibana , 其中ELasticsearch负责日志保存和搜索，FileBeat负责收集日志，Kibana 负责界面,当然EFK和大名鼎鼎的ELK只有一个区别，那就是EFK把ELK的Logstash替换成了FileBeat，因为Filebeat相对于Logstash来说有2个好处：
  
  侵入低，无需修改程序目前任何代码和配置
  
  相对于Logstash来说性能高，Logstash对于IO占用很大
- EFK的架构如下所示
修改证书时间
- 原因：以kubeadmin安装的kubernetes集群，证书的有效时间是1年，超过一年就无法使用
- 查看有效时间
cd /etc/kubernetes/pki openssl x509 -in apiserver.crt -text -noout --- Validity Not Before: Apr 2 02:42:39 2020 GMT Not After : Apr 2 02:42:39 2021 GMT --- apiserver 只有一年的默认时间使用期限 -------------
- go环境部署
wget https://dl.google.com/go/go1.12.7.linux-amd64.tar.gz tar -zxvf go1.12.1.linux-amd64.tar.gz -C /usr/local vim /etc/profile --- export PATH=$PATH:/usr/local/go/bin --- source /etc/profile
- 下载源码
git clone https://github.com/kubernetes/kubernetes.git git checkout -b remotes/origin/release-1.15.1 v1.15.1
- 修改kubeadmin源码
vim staging/src/k8s.io/client-go/util/cert/cert.go # kubeadm 1.14 版本之前 vim cmd/kubeadm/app/util/pkiutil/pki_helpers.go # kubeadm 1.14 至今 ---- const duration3650d = time.Hour * 24 * 365 * 10 NotAfter: time.Now().Add(duration365d).UTC(), ---- make WHAT=cmd/kubeadm GOFLAGS=-v cp _output/bin/kubeadm /root/kubeadm-new ---- cp -p /usr/bin/kubeadmn /usr/bin/kubeadmn.old cp -p /root/kubeadm-new /usr/bin/kubeadm chmod +x /usr/bin/kubeadmn ---- cd /etc/kubernetes/ cp -ap pki pki.old ---- cd /root/k8s-install/core kubeadm alpha certs renew all --config=./kubeadm-config.yaml
- 验证是否修改成功
openssl x509 -in apiserver.crt -text -noout
查看全文