简介
-
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的状态
-
Pending：Pod已被Kubernetes系统接受，但尚未创建一个或多个Container
-
Running：Pod已绑定到节点，并且已创建所有Container
-
Succeeded：Pod中的所有容器都已成功终止，并且不会重新启动
-
Failed：Pod中的所有容器都已终止，并且至少有一个Container已终止失败
-
Unknown：由于某种原因，无法获得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生命周期
-
启动pause容器，每个Pod默认具有，主要是初始化网络和数据卷
-
pause串行启动初始化容器（initC），只到所有的初始化容器都成功执行
-
pause并行启动主容器（mainC），启动开始钩子（post start），启动探针（liveness probe，readness probe）
-
在主容器结束之前，调用结束钩子（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优先调度到具有亲和性的节点上运行
-
nodeSelector：节点满足label要求才能得到调度，简单粗暴
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-
-
亲和性支持的operator：
In,NotIn,Exists,DoesNotExist,Gt,Lt -
requiredDuringSchedulingIgnoredDuringExecution：硬条件，节点满足条件就可以得到调度，不满足条件就调度
-
preferredDuringSchedulingIgnoredDuringExecution：软条件，尽量在满足条件的节点上调度，如果没有满足条件的节点也可以得到调度
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之间的相互靠近和排斥
-
具有亲和性的Pod被调度到同一节点域上运行，一个节点域包含多个节点，通过节点标签和topologyKey指定
-
具有反亲和性的Pod会被调度到不同的节点域上运行
-
Pod的亲和性和反亲和性都具有硬条件和软条件
-
preferredDuringSchedulingIgnoredDuringExecution：硬条件
-
requiredDuringSchedulingIgnoredDuringExecution：软条件
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
-
-
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