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,甚至可以控制多少流量流入