- 浏览: 565212 次
- 性别:
- 来自: 北京
文章分类
- 全部博客 (267)
- 随笔 (4)
- Spring (13)
- Java (61)
- HTTP (3)
- Windows (1)
- CI(Continuous Integration) (3)
- Dozer (1)
- Apache (11)
- DB (7)
- Architecture (41)
- Design Patterns (11)
- Test (5)
- Agile (1)
- ORM (3)
- PMP (2)
- ESB (2)
- Maven (5)
- IDE (1)
- Camel (1)
- Webservice (3)
- MySQL (6)
- CentOS (14)
- Linux (19)
- BI (3)
- RPC (2)
- Cluster (9)
- NoSQL (7)
- Oracle (25)
- Loadbalance (7)
- Web (5)
- tomcat (1)
- freemarker (1)
- 制造 (0)
最新评论
-
panamera:
如果设置了连接需要密码,Dynamic Broker-Clus ...
ActiveMQ 集群配置 -
panamera:
请问你的最后一种模式Broker-C节点是不是应该也要修改持久 ...
ActiveMQ 集群配置 -
maosheng:
longshao_feng 写道楼主使用 文件共享 模式的ma ...
ActiveMQ 集群配置 -
longshao_feng:
楼主使用 文件共享 模式的master-slave,produ ...
ActiveMQ 集群配置 -
tanglanwen:
感触很深,必定谨记!
少走弯路的十条忠告
容器的三大好处
1.资源隔离与利用率提升
2.秒级弹性
3.环境一致性,简化交付
容器底层关键技术--Linux Cgroup
Docker使用Linux Cgroup 技术来实现容器实例的资源管理
1.memory:限制cgroup中的任务所使用的内存上限
2.cpu:使用调度程序提供对CPU的cgroup任务访问
3.Cpuset:为cgroup中的任务分配独立CPU和内存节点
4.Blkio:为块设备设定输入/输出限制
容器底层关键技术--Linux Namespace
1.PID namespace:隔离不同用户的进程,不同的namespace中可以有相同的pid
2.UTS namespace:允许每个容器拥有独立的hostname和domain name,使其在网络上可以被视为独立的节点
3.IPC namespace:保证容器间的进程交互,进行信号量、消息队列和共享内存的隔离
4.Network namespace:实现网路隔离,每个net namespace有独立的network devices,ip addresses,ip routing tables,/proc/net 目录
5.Mount namespace:隔离不用namespace的进程看到的目录结构,每个namespace的容器在/proc/mounts的信息只包含所在的namespace的mount point
6.User namespace:允许每个容器可以有不同的user和group id
容器底层关键技术--联合文件系统
概念:一个基于文件的接口,通过把一组目录交错起来,形成一个单一的视图
优点:
1.多个容器可以共享image存储,节省存储空间
2.部署多个容器时,base image可以避免多次拷贝,实现快速部署Docker目前支持的联合文件系统种类包括devicemapper、overlay2、aufs、btrfs、vfs
kubernets模型对象
Pod:能够创建、调度和管理的最小部署单元,是一组容器的集合,而不是单独的应用容器
同一个Pod里的容器共享同一个网络命名空间、IP地址及端口空间
从生命周期来说,Pod是短暂的而不是长久的应用。Pods被调度到节点,保持在这个节点上直到被销毁
Pod详解--容器
容器分类:
1、Infrastructure Container:基础容器
用户不可见,无需感知
维护这个Pod网络空间
2、InitContainer:初始化容器,一般用于服务等待处理以及注册Pod信息等
先于业务容器开始执行
顺序执行,执行成功退出(exit 0),全部执行成功后开始启动业务容器
3、Containers:业务容器
并行启动,启动成功后一直Running
容器基本组成
spec:
imagePullSecrets:
- name: default-secret
containers:
- image: kube-dns:1.0.0
imagePullPolicy: IfNotPresent
command:
- /bin/sh
- -c
- /kube-dns 1>>/var/log/skydns.log 2>&1 --domain=cluster.local. --dns-port=10053
--config-dir=/kube-dns-config --v=2
resources:
limits:
cpu: 100m
memory: 512Mi
requests:
cpu: 100m
memory: 100Mi
- livenessProbe:
failureThreshold: 5
exec:
command:
- “/bin/sh”,
- “-c”
- “echo ‘iam ok’”
initialDelaySeconds: 60
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 5
readinessProbe:
failureThreshold: 3
httpGet:
path: /readiness
port: 8081
scheme: HTTP
initialDelaySeconds: 3
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 5
- env:
- name: APP_NAME
value: test
- name: USER_NAME
valueFrom:
secretKeyRef:
key: username
name: secret
envFrom:
- configMapRef:
name: config
volumeMounts:
- mountPath: /usr/local/config
name: cfg
- mountPath: /usr/local/secret
name: sct
- mountPath: /usr/local/disk
name: pvc-153085714479448980
- mountPath: /usr/local/host
name: host
volumes:
- configMap:
defaultMode: 420
items:
- key: age
path: age
name: config
name: cfg
- name: sct
secret:
defaultMode: 420
secretName: secret
- name: pvc-153085714479448980
persistentVolumeClaim:
claimName: pvc-153085714479448980
- name: host
hostPath:
path: /opt/
dnsPolicy: ClusterFirst
镜像部分:
镜像地址和拉取策略
拉取镜像的认证凭据
imagePullSecrets:
- name: default-secret
containers:
- image: kube-dns:1.0.0
imagePullPolicy: IfNotPresent
启动命令:
command:替换docker容器的entrypoint
args:作为docker容器entrypoint的入参
command:
- /bin/sh
- -c
- /kube-dns 1>>/var/log/skydns.log 2>&1 --domain=cluster.local. --dns-port=10053
--config-dir=/kube-dns-config --v=2
计算资源:
请求值:调度依据
限制值:容器最大能使用的规格
resources:
limits:
cpu: 100m
memory: 512Mi
requests:
cpu: 100m
memory: 100Mi
健康检查:
分命令行方式、httpGet请求方式以及TCPSocket方式。
1、业务探针(readinessProbe)
探测不正常后,不会重启容器,只会拿掉服务后端的endpoints
readinessProbe:
failureThreshold: 3
httpGet:
path: /readiness
port: 8081
scheme: HTTP
initialDelaySeconds: 3
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 5
2、存活探针(livenessProbe)
探测不正常后,会重启容器
- livenessProbe:
failureThreshold: 5
exec:
command:
- “/bin/sh”,
- “-c”
- “echo ‘iam ok’”
initialDelaySeconds: 60
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 5
Pod详解-外部输入
Pod可以接收的外部输入方式:环境变量、配置文件以及密钥。
1、环境变量:使用简单,但一旦变更后必须重启容器。
Key-value自定义
From 配置文件(configmap)
From 密钥(Secret)
- env:
- name: APP_NAME
value: test
- name: USER_NAME
valueFrom:
secretKeyRef:
key: username
name: secret
envFrom:
- configMapRef:
name: config
2、以卷形式挂载到容器内使用,权限可控。
配置文件(configmap)
密钥(secret)
配置文件、密钥大小不能超过1M
Secret有类型区分,不同类型有不同校验方式,输入的value需base64加密
volumeMounts:
- mountPath: /usr/local/config
name: cfg
- mountPath: /usr/local/secret
name: sct
- mountPath: /usr/local/host
name: host
volumes:
- configMap:
defaultMode: 420
items:
- key: age
path: age
name: config
name: cfg
- name: sct
secret:
defaultMode: 420
secretName: secret
- name: host
hostPath:
path: /opt/
Pod详解-持久化存储
1、主机hostpath
必须要求Pod调度到固定节点上
volumeMounts:
- mountPath: /usr/local/disk
name: pvc-153085714479448980
volumes:
- name: pvc-153085714479448980
persistentVolumeClaim:
claimName: pvc-153085714479448980
2、云存储
多类型选择,如云硬盘,文件存储,对象存储等
不用担心Pod迁移
volumeMounts:
- mountPath: /usr/local/host
name: host
volumes:
- name: host
hostPath:
path: /opt/
Pod详解-服务域名发现
dnsPolicy:Pod内域名解析的策略
ClusterFirst:使用kube-dns作为域名解析服务器
Default:使用节点(kubelet)指定的域名服务器解析域名
ClusterFirstWithHostNet:当Pod使用主机网络部署时使用
spec:
containers:
dnsPolicy: ClusterFirst
Pod与工作负载的关系
通过label-selector相关联
Pod通过工作负载实现应用的运维,如伸缩、升级等
关键工作负载-ReplicaSet(无状态模式):
ReplicaSet—副本控制器
确保Pod的一定数量的份数(replica)在运行。如果超过这个数量,控制器会杀死一些,如果少了,控制器会启动一些。
ReplicaSet用于解决pod的扩容和缩容问题。
通常用于无状态应用
apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
name: frontend
spec:
replicas: 3
selector:
matchLabels:
tier: frontend
matchExpressions:
- {key: tier, operator: In, values: [frontend]} // NotIn, Exists, DoesNotExist
template:
metadata:
labels:
app: guestbook
tier: frontend
spec:
containers:
- name: php-redis
image: gcr.io/google_samples/gb-
frontend:v3
resources:
requests:
cpu: 100m
memory: 100Mi
env:
- name: GET_HOSTS_FROM
value: dns
ports:
- containerPort: 80
关键工作负载-Deployment(无状态模式)
Kubernetes Deployment提供了官方的用于更新Pod和Replica Set(下一代的Replication Controller)的方法,您可以在Deployment对象中只描述您所期望的理想状态(预期的运行状态),
Deployment控制器为您将现在的实际状态转换成您期望的状态;
Deployment集成了上线部署、滚动升级、创建副本、暂停上线任务,恢复上线任务,回滚到以前
某一版本(成功/稳定)的Deployment等功能,在某种程度上,Deployment可以帮我们实现无人值守的上线,大大降低我们的上线过程的复杂沟通、操作风险。
Deployment的典型用例:
使用Deployment来启动(上线/部署)一个Pod或者ReplicaSet
检查一个Deployment是否成功执行
更新Deployment来重新创建相应的Pods(例如,需要使用一个新的Image)
如果现有的Deployment不稳定,那么回滚到一个早期的稳定的Deployment版本
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
关键工作负载-StatefulSet(有状态模式)
StatefulSet—有状态应用
用于解决各个pod实例独立生命周期管理,提供各个实例的启动顺序和唯一性
稳定,唯一的网络标识符。
稳定,持久存储。
有序的,优雅的部署和扩展。
有序,优雅的删除和终止。
有序的自动滚动更新。
严格的启动/删除顺序
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: web
spec:
selector:
matchLabels:
app: nginx # has to match .spec.template.metadata.labels
serviceName: "nginx"
replicas: 3 # by default is 1
template:
metadata:
labels:
app: nginx # has to match .spec.selector.matchLabels
spec:
terminationGracePeriodSeconds: 10
containers:
- name: nginx
image: k8s.gcr.io/nginx-slim:0.8
ports:
- containerPort: 80
name: web
volumeMounts:
- name: www
mountPath: /usr/share/nginx/html
volumeClaimTemplates:
- metadata:
name: www
spec:
accessModes: [ "ReadWriteOnce" ]
storageClassName: "my-storage-class"
关键工作负载-DaemonSet(守护进程模式)
DaemonSet能够让所有(或者一些特定:NodeSelector或NodeAffinity指定Node)的Node节点运行同一个pod。当节点加入到kubernetes集群中,pod会被(DaemonSet)调度到该节点上运行,当节点从kubernetes集群中被移除,
被(DaemonSet)调度的pod会被移除,如果删除DaemonSet,所有跟这个DaemonSet相关的pods都会被删除。
在使用kubernetes来运行应用时,很多时候我们需要在一个区域(zone)或者所有Node上运行同一个守护进程(pod),例如如下场景:
每个Node上运行一个分布式存储的守护进程,例如glusterd,ceph
运行日志采集器在每个Node上,例如fluentd,logstash
运行监控的采集端在每个Node,例如prometheus node exporter,collectd等
支持滚动升级,支持级联/非级联删除
apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
name: tomcat-ds
spec:
template:
metadata:
labels:
app: tomcat
spec:
containers:
- name: tomcat
image: tomcat:8.0.30-jre8
ports:
- containerPort: 8080
关键工作负载-Job
分为普通任务(Job)和定时任务(CronJob)
一次性执行,非堵塞
适合CI,视频解码,基因测序等业务
普通任务(Job):
- 保证指定数量Pod成功运行结束 - completions
- 支持并行 - parallelism
- 支持错误自动重试(10s, 20s, 40s,… 6min)
- 删除Job会触发对应Pod删除
定时任务(CronJob):
- 基于时间调度的Job( Cron 格式)
- 用户可以暂停/恢复Job的周期性调度 .spec.suspend={true,false}
- 管理Job -> Pod
apiVersion: batch/v1
kind: Job
metadata:
name: pi
spec:
backoffLimit: 5
activeDeadlineSeconds: 100
template:
metadata:
name: pi
spec:
containers:
- name: pi
image: perl
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
restartPolicy: Never
---
apiVersion: batch/v1
kind: CronJob
metadata:
name: hello
spec:
schedule: "*/1 * * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: hello
image: busybox
args:
- /bin/sh
- -c
- date; echo Hello from the Kubernetes cluster
restartPolicy: OnFailure
Pod与服务的关系
通过label-selector相关联
通过服务实现Pod的负载均衡能力:
Service:实现TCP/UDP 4层负载均衡能力
Ingress:实现HTTP 7层负载均衡能力
Service定义了pods的逻辑集合和访问这个集合的策略。Pods集合是通过定义Service时提供的Label选择器完成的
Service的引入旨在保证pod的动态变化对访问端透明,访问端只需要知道service的地址,由service来提供代理
Service的抽象使得前端客户和后端Pods进行了解耦
支持ClusterIP,NodePort以及LoadBalancer三种类型:
ClusterIP
- 默认类型,自动分配集群内部可以访问的虚IP——Cluster IP。
NodePort
- 为Service在Kubernetes集群的每个Node上分配一个端口,即NodePort,集群内/外部
可基于任何一个NodeIP:NodePort的形式来访问Service。
LoadBalancer
- 需要跑在特定的cloud provider上
- Service Controller自动创建一个外部LB并配置安全组
- 对集群内访问,kube-proxy用iptables或ipvs实现了云服务提供商LB的部分功能:L4转发,
安全组规则等。
Service的底层实现有userspace、iptables和ipvs三种模式
kind: Service
apiVersion: v1
metadata:
name: my-service
spec:
selector:
app: A
ports:
- protocol: TCP
port: 80
targetPort: 9376
nodePort: 30061
type: ClusterIP
Service类型: ClusterIP、NodePort、 LoadBalancer
Ingress:Ingress基于service实现7层路由转发能力
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: test
annotations:
ingress.kubernetes.io/rewrite-target: /
spec:
rules:
- host: foo.bar.com
http:
paths:
- path: /foo
backend:
serviceName: service-a
servicePort: 80
- path: /bar
backend:
serviceName: service-b
servicePort: 80
Kube-apiserver:是整个kubernetes集群的“灵魂”,是信息的汇集中枢,提供了所有内部和外部的API请求操作的唯一入口,同时也负责整个集群的认证、授权、访问控制、服务发现等等能力。
Kubernetes基于list-watch机制的控制器架构
Controller-manager:watch各类set,处理生命周期事件;定期list做同步处理,保证最终一致
Scheduler:list & watch集群中的node,供调度时使用;watch未调度的Pod,进行多策略调度,为Pod找到一个合适的Node
Kubelet:watch被调度到本节点的Pod,执行生命周期动作
1、kubectl调用api-server创建ReplicaSet---->
2、api-server在etcd创建ReplicaSet---->
3、etcd向api-server上报事件ReplicaSet Created---->
4.0、controller-manager向api-server发起watch ReplicaSet 4.1、api-server向controller-manager上报事件ReplicaSet Created---->
5、controller-manager调用api-server创建Pod---->
6、api-server在etcd创建Pod ---->
7、etcd 向api-server上报事件Pod Created---->
8.0、sheduler向api-server发起watch Pod(destNode="") 8.1、api-server向sheduler上报事件Pod Created---->
9、scheduler调用api-server更新Pod按调度结果绑定node---->
10、api-server在etcd更新Pod---->
11、etcd向api-server上报事件Pod Bound(Updated)---->
12.0、kubelet向api-server发起watch Pod(destNode="myNode") 12.1、api-server向kubelet上报事件Pod Bound(Updated)
scheduler调度器的内部流程:
1、通过NodeLister获取所有节点信息;
2、整合scheduled pods和assume pods,合并到pods,作为所有已调度Pod信息;
3、从pods中整理出node-pods的对应关系表nodeNameToInfo;
4、过滤掉不合适的节点;
5、给剩下的节点依次打分;
6、在分数最高的nodes中随机选择一个节点用于绑定。这是为了避免分数最高的节点被几次调度撞车 。
1.资源隔离与利用率提升
2.秒级弹性
3.环境一致性,简化交付
容器底层关键技术--Linux Cgroup
Docker使用Linux Cgroup 技术来实现容器实例的资源管理
1.memory:限制cgroup中的任务所使用的内存上限
2.cpu:使用调度程序提供对CPU的cgroup任务访问
3.Cpuset:为cgroup中的任务分配独立CPU和内存节点
4.Blkio:为块设备设定输入/输出限制
容器底层关键技术--Linux Namespace
1.PID namespace:隔离不同用户的进程,不同的namespace中可以有相同的pid
2.UTS namespace:允许每个容器拥有独立的hostname和domain name,使其在网络上可以被视为独立的节点
3.IPC namespace:保证容器间的进程交互,进行信号量、消息队列和共享内存的隔离
4.Network namespace:实现网路隔离,每个net namespace有独立的network devices,ip addresses,ip routing tables,/proc/net 目录
5.Mount namespace:隔离不用namespace的进程看到的目录结构,每个namespace的容器在/proc/mounts的信息只包含所在的namespace的mount point
6.User namespace:允许每个容器可以有不同的user和group id
容器底层关键技术--联合文件系统
概念:一个基于文件的接口,通过把一组目录交错起来,形成一个单一的视图
优点:
1.多个容器可以共享image存储,节省存储空间
2.部署多个容器时,base image可以避免多次拷贝,实现快速部署Docker目前支持的联合文件系统种类包括devicemapper、overlay2、aufs、btrfs、vfs
kubernets模型对象
Pod:能够创建、调度和管理的最小部署单元,是一组容器的集合,而不是单独的应用容器
同一个Pod里的容器共享同一个网络命名空间、IP地址及端口空间
从生命周期来说,Pod是短暂的而不是长久的应用。Pods被调度到节点,保持在这个节点上直到被销毁
Pod详解--容器
容器分类:
1、Infrastructure Container:基础容器
用户不可见,无需感知
维护这个Pod网络空间
2、InitContainer:初始化容器,一般用于服务等待处理以及注册Pod信息等
先于业务容器开始执行
顺序执行,执行成功退出(exit 0),全部执行成功后开始启动业务容器
3、Containers:业务容器
并行启动,启动成功后一直Running
容器基本组成
spec:
imagePullSecrets:
- name: default-secret
containers:
- image: kube-dns:1.0.0
imagePullPolicy: IfNotPresent
command:
- /bin/sh
- -c
- /kube-dns 1>>/var/log/skydns.log 2>&1 --domain=cluster.local. --dns-port=10053
--config-dir=/kube-dns-config --v=2
resources:
limits:
cpu: 100m
memory: 512Mi
requests:
cpu: 100m
memory: 100Mi
- livenessProbe:
failureThreshold: 5
exec:
command:
- “/bin/sh”,
- “-c”
- “echo ‘iam ok’”
initialDelaySeconds: 60
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 5
readinessProbe:
failureThreshold: 3
httpGet:
path: /readiness
port: 8081
scheme: HTTP
initialDelaySeconds: 3
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 5
- env:
- name: APP_NAME
value: test
- name: USER_NAME
valueFrom:
secretKeyRef:
key: username
name: secret
envFrom:
- configMapRef:
name: config
volumeMounts:
- mountPath: /usr/local/config
name: cfg
- mountPath: /usr/local/secret
name: sct
- mountPath: /usr/local/disk
name: pvc-153085714479448980
- mountPath: /usr/local/host
name: host
volumes:
- configMap:
defaultMode: 420
items:
- key: age
path: age
name: config
name: cfg
- name: sct
secret:
defaultMode: 420
secretName: secret
- name: pvc-153085714479448980
persistentVolumeClaim:
claimName: pvc-153085714479448980
- name: host
hostPath:
path: /opt/
dnsPolicy: ClusterFirst
镜像部分:
镜像地址和拉取策略
拉取镜像的认证凭据
imagePullSecrets:
- name: default-secret
containers:
- image: kube-dns:1.0.0
imagePullPolicy: IfNotPresent
启动命令:
command:替换docker容器的entrypoint
args:作为docker容器entrypoint的入参
command:
- /bin/sh
- -c
- /kube-dns 1>>/var/log/skydns.log 2>&1 --domain=cluster.local. --dns-port=10053
--config-dir=/kube-dns-config --v=2
计算资源:
请求值:调度依据
限制值:容器最大能使用的规格
resources:
limits:
cpu: 100m
memory: 512Mi
requests:
cpu: 100m
memory: 100Mi
健康检查:
分命令行方式、httpGet请求方式以及TCPSocket方式。
1、业务探针(readinessProbe)
探测不正常后,不会重启容器,只会拿掉服务后端的endpoints
readinessProbe:
failureThreshold: 3
httpGet:
path: /readiness
port: 8081
scheme: HTTP
initialDelaySeconds: 3
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 5
2、存活探针(livenessProbe)
探测不正常后,会重启容器
- livenessProbe:
failureThreshold: 5
exec:
command:
- “/bin/sh”,
- “-c”
- “echo ‘iam ok’”
initialDelaySeconds: 60
periodSeconds: 10
successThreshold: 1
timeoutSeconds: 5
Pod详解-外部输入
Pod可以接收的外部输入方式:环境变量、配置文件以及密钥。
1、环境变量:使用简单,但一旦变更后必须重启容器。
Key-value自定义
From 配置文件(configmap)
From 密钥(Secret)
- env:
- name: APP_NAME
value: test
- name: USER_NAME
valueFrom:
secretKeyRef:
key: username
name: secret
envFrom:
- configMapRef:
name: config
2、以卷形式挂载到容器内使用,权限可控。
配置文件(configmap)
密钥(secret)
配置文件、密钥大小不能超过1M
Secret有类型区分,不同类型有不同校验方式,输入的value需base64加密
volumeMounts:
- mountPath: /usr/local/config
name: cfg
- mountPath: /usr/local/secret
name: sct
- mountPath: /usr/local/host
name: host
volumes:
- configMap:
defaultMode: 420
items:
- key: age
path: age
name: config
name: cfg
- name: sct
secret:
defaultMode: 420
secretName: secret
- name: host
hostPath:
path: /opt/
Pod详解-持久化存储
1、主机hostpath
必须要求Pod调度到固定节点上
volumeMounts:
- mountPath: /usr/local/disk
name: pvc-153085714479448980
volumes:
- name: pvc-153085714479448980
persistentVolumeClaim:
claimName: pvc-153085714479448980
2、云存储
多类型选择,如云硬盘,文件存储,对象存储等
不用担心Pod迁移
volumeMounts:
- mountPath: /usr/local/host
name: host
volumes:
- name: host
hostPath:
path: /opt/
Pod详解-服务域名发现
dnsPolicy:Pod内域名解析的策略
ClusterFirst:使用kube-dns作为域名解析服务器
Default:使用节点(kubelet)指定的域名服务器解析域名
ClusterFirstWithHostNet:当Pod使用主机网络部署时使用
spec:
containers:
dnsPolicy: ClusterFirst
Pod与工作负载的关系
通过label-selector相关联
Pod通过工作负载实现应用的运维,如伸缩、升级等
关键工作负载-ReplicaSet(无状态模式):
ReplicaSet—副本控制器
确保Pod的一定数量的份数(replica)在运行。如果超过这个数量,控制器会杀死一些,如果少了,控制器会启动一些。
ReplicaSet用于解决pod的扩容和缩容问题。
通常用于无状态应用
apiVersion: extensions/v1beta1
kind: ReplicaSet
metadata:
name: frontend
spec:
replicas: 3
selector:
matchLabels:
tier: frontend
matchExpressions:
- {key: tier, operator: In, values: [frontend]} // NotIn, Exists, DoesNotExist
template:
metadata:
labels:
app: guestbook
tier: frontend
spec:
containers:
- name: php-redis
image: gcr.io/google_samples/gb-
frontend:v3
resources:
requests:
cpu: 100m
memory: 100Mi
env:
- name: GET_HOSTS_FROM
value: dns
ports:
- containerPort: 80
关键工作负载-Deployment(无状态模式)
Kubernetes Deployment提供了官方的用于更新Pod和Replica Set(下一代的Replication Controller)的方法,您可以在Deployment对象中只描述您所期望的理想状态(预期的运行状态),
Deployment控制器为您将现在的实际状态转换成您期望的状态;
Deployment集成了上线部署、滚动升级、创建副本、暂停上线任务,恢复上线任务,回滚到以前
某一版本(成功/稳定)的Deployment等功能,在某种程度上,Deployment可以帮我们实现无人值守的上线,大大降低我们的上线过程的复杂沟通、操作风险。
Deployment的典型用例:
使用Deployment来启动(上线/部署)一个Pod或者ReplicaSet
检查一个Deployment是否成功执行
更新Deployment来重新创建相应的Pods(例如,需要使用一个新的Image)
如果现有的Deployment不稳定,那么回滚到一个早期的稳定的Deployment版本
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: nginx-deployment
spec:
replicas: 3
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
关键工作负载-StatefulSet(有状态模式)
StatefulSet—有状态应用
用于解决各个pod实例独立生命周期管理,提供各个实例的启动顺序和唯一性
稳定,唯一的网络标识符。
稳定,持久存储。
有序的,优雅的部署和扩展。
有序,优雅的删除和终止。
有序的自动滚动更新。
严格的启动/删除顺序
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: web
spec:
selector:
matchLabels:
app: nginx # has to match .spec.template.metadata.labels
serviceName: "nginx"
replicas: 3 # by default is 1
template:
metadata:
labels:
app: nginx # has to match .spec.selector.matchLabels
spec:
terminationGracePeriodSeconds: 10
containers:
- name: nginx
image: k8s.gcr.io/nginx-slim:0.8
ports:
- containerPort: 80
name: web
volumeMounts:
- name: www
mountPath: /usr/share/nginx/html
volumeClaimTemplates:
- metadata:
name: www
spec:
accessModes: [ "ReadWriteOnce" ]
storageClassName: "my-storage-class"
关键工作负载-DaemonSet(守护进程模式)
DaemonSet能够让所有(或者一些特定:NodeSelector或NodeAffinity指定Node)的Node节点运行同一个pod。当节点加入到kubernetes集群中,pod会被(DaemonSet)调度到该节点上运行,当节点从kubernetes集群中被移除,
被(DaemonSet)调度的pod会被移除,如果删除DaemonSet,所有跟这个DaemonSet相关的pods都会被删除。
在使用kubernetes来运行应用时,很多时候我们需要在一个区域(zone)或者所有Node上运行同一个守护进程(pod),例如如下场景:
每个Node上运行一个分布式存储的守护进程,例如glusterd,ceph
运行日志采集器在每个Node上,例如fluentd,logstash
运行监控的采集端在每个Node,例如prometheus node exporter,collectd等
支持滚动升级,支持级联/非级联删除
apiVersion: extensions/v1beta1
kind: DaemonSet
metadata:
name: tomcat-ds
spec:
template:
metadata:
labels:
app: tomcat
spec:
containers:
- name: tomcat
image: tomcat:8.0.30-jre8
ports:
- containerPort: 8080
关键工作负载-Job
分为普通任务(Job)和定时任务(CronJob)
一次性执行,非堵塞
适合CI,视频解码,基因测序等业务
普通任务(Job):
- 保证指定数量Pod成功运行结束 - completions
- 支持并行 - parallelism
- 支持错误自动重试(10s, 20s, 40s,… 6min)
- 删除Job会触发对应Pod删除
定时任务(CronJob):
- 基于时间调度的Job( Cron 格式)
- 用户可以暂停/恢复Job的周期性调度 .spec.suspend={true,false}
- 管理Job -> Pod
apiVersion: batch/v1
kind: Job
metadata:
name: pi
spec:
backoffLimit: 5
activeDeadlineSeconds: 100
template:
metadata:
name: pi
spec:
containers:
- name: pi
image: perl
command: ["perl", "-Mbignum=bpi", "-wle", "print bpi(2000)"]
restartPolicy: Never
---
apiVersion: batch/v1
kind: CronJob
metadata:
name: hello
spec:
schedule: "*/1 * * * *"
jobTemplate:
spec:
template:
spec:
containers:
- name: hello
image: busybox
args:
- /bin/sh
- -c
- date; echo Hello from the Kubernetes cluster
restartPolicy: OnFailure
Pod与服务的关系
通过label-selector相关联
通过服务实现Pod的负载均衡能力:
Service:实现TCP/UDP 4层负载均衡能力
Ingress:实现HTTP 7层负载均衡能力
Service定义了pods的逻辑集合和访问这个集合的策略。Pods集合是通过定义Service时提供的Label选择器完成的
Service的引入旨在保证pod的动态变化对访问端透明,访问端只需要知道service的地址,由service来提供代理
Service的抽象使得前端客户和后端Pods进行了解耦
支持ClusterIP,NodePort以及LoadBalancer三种类型:
ClusterIP
- 默认类型,自动分配集群内部可以访问的虚IP——Cluster IP。
NodePort
- 为Service在Kubernetes集群的每个Node上分配一个端口,即NodePort,集群内/外部
可基于任何一个NodeIP:NodePort的形式来访问Service。
LoadBalancer
- 需要跑在特定的cloud provider上
- Service Controller自动创建一个外部LB并配置安全组
- 对集群内访问,kube-proxy用iptables或ipvs实现了云服务提供商LB的部分功能:L4转发,
安全组规则等。
Service的底层实现有userspace、iptables和ipvs三种模式
kind: Service
apiVersion: v1
metadata:
name: my-service
spec:
selector:
app: A
ports:
- protocol: TCP
port: 80
targetPort: 9376
nodePort: 30061
type: ClusterIP
Service类型: ClusterIP、NodePort、 LoadBalancer
Ingress:Ingress基于service实现7层路由转发能力
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: test
annotations:
ingress.kubernetes.io/rewrite-target: /
spec:
rules:
- host: foo.bar.com
http:
paths:
- path: /foo
backend:
serviceName: service-a
servicePort: 80
- path: /bar
backend:
serviceName: service-b
servicePort: 80
Kube-apiserver:是整个kubernetes集群的“灵魂”,是信息的汇集中枢,提供了所有内部和外部的API请求操作的唯一入口,同时也负责整个集群的认证、授权、访问控制、服务发现等等能力。
Kubernetes基于list-watch机制的控制器架构
Controller-manager:watch各类set,处理生命周期事件;定期list做同步处理,保证最终一致
Scheduler:list & watch集群中的node,供调度时使用;watch未调度的Pod,进行多策略调度,为Pod找到一个合适的Node
Kubelet:watch被调度到本节点的Pod,执行生命周期动作
1、kubectl调用api-server创建ReplicaSet---->
2、api-server在etcd创建ReplicaSet---->
3、etcd向api-server上报事件ReplicaSet Created---->
4.0、controller-manager向api-server发起watch ReplicaSet 4.1、api-server向controller-manager上报事件ReplicaSet Created---->
5、controller-manager调用api-server创建Pod---->
6、api-server在etcd创建Pod ---->
7、etcd 向api-server上报事件Pod Created---->
8.0、sheduler向api-server发起watch Pod(destNode="") 8.1、api-server向sheduler上报事件Pod Created---->
9、scheduler调用api-server更新Pod按调度结果绑定node---->
10、api-server在etcd更新Pod---->
11、etcd向api-server上报事件Pod Bound(Updated)---->
12.0、kubelet向api-server发起watch Pod(destNode="myNode") 12.1、api-server向kubelet上报事件Pod Bound(Updated)
scheduler调度器的内部流程:
1、通过NodeLister获取所有节点信息;
2、整合scheduled pods和assume pods,合并到pods,作为所有已调度Pod信息;
3、从pods中整理出node-pods的对应关系表nodeNameToInfo;
4、过滤掉不合适的节点;
5、给剩下的节点依次打分;
6、在分数最高的nodes中随机选择一个节点用于绑定。这是为了避免分数最高的节点被几次调度撞车 。
发表评论
-
HTTPS的加密原理解读
2021-12-31 11:25 275一、为什么需要加密? 因为http的内容是明文传输的,明文数据 ... -
容器技术的基石: cgroup、namespace和联合文件系统
2021-12-09 10:47 675Docker 是基于 Linux Kernel 的 Names ... -
链路追踪skywalking安装部署
2021-10-21 12:06 788APM 安装部署: 一、下载 版本目录地址:http://a ... -
自动化运维 Ansible 安装部署
2021-08-20 19:06 816一、概述 Ansible 实现了批量系统配置、批量程序部署、 ... -
Linux 下 Kafka Cluster 搭建
2021-07-08 11:23 951概述 http://kafka.apachecn.org/q ... -
ELK RPM 安装配置
2021-06-22 18:59 594相关组件: 1)filebeat。用于收集日志组件,经测试其 ... -
在Kubernetes上部署 Redis 三主三从 集群
2021-03-10 16:25 623NFS搭建见: Linux NFS搭建与配置(https:// ... -
docker-compose 部署ELK(logstash->elasticsearch->kibana)
2020-11-11 18:02 1545概述: ELK是三个开源软件的缩写,分别表示:elastic ... -
Kubernetes1.16.3下部署node-exporter+alertmanager+prometheus+grafana 监控系统
2020-10-28 10:48 1029准备工作 建议将所有的yaml文件存在如下目录: # mkd ... -
Linux NFS 搭建与配置
2020-10-21 17:58 402一、NFS 介绍 NFS 是 Network FileSys ... -
K8S 备份及升级
2020-10-20 15:48 851一、准备工作 查看集群版本: # kubectl get no ... -
API 网关 kong 的 konga 配置使用
2020-09-23 10:46 4081一、Kong 概述: kong的 ... -
Kubernetes 应用编排、管理与运维
2020-08-24 16:40 558一、kubectl 运维命令 kubectl control ... -
API 网关 kong/konga 安装部署
2020-08-25 17:34 554一、概述 Kong是Mashape开 ... -
Linux 下 Redis Cluster 搭建
2020-08-13 09:14 699Redis集群演变过程: 单 ... -
Kubernetes离线安装的本地yum源构建
2020-08-08 22:41 492一、需求场景 在K8S的使用过程中有时候会遇到在一些无法上网 ... -
Kubernetes 证书延期
2020-08-01 22:28 427一、概述 kubeadm 是 kubernetes 提供的一 ... -
kubeadm方式部署安装kubernetes
2020-07-29 08:01 2319一、前提准备: 0、升级更新系统(切记升级一下,曾被坑过) ... -
Kubernetes 部署 Nginx 集群
2020-07-20 09:32 825一.设置标签 为了保证nginx之能分配到nginx服务器需要 ... -
Prometheus 外部监控 Kubernetes 集群
2020-07-10 15:59 1988大多情况都是将 Prometheus 通过 yaml 安装在 ...
相关推荐
云原生Docker和K8S 03-K8S架构和流程
云原生Docker和K8S 01-Docker基础 云原生Docker和K8S 01-Docker基础是 Docker 和 Kubernetes 的基础知识介绍。Docker 是一种容器化技术,允许用户在隔离的环境中运行应用程序,而不需要创建虚拟机。Kubernetes 是一...
云原生Docker和K8S 02-Docker进阶 本资源主要讲解了如何使用Jenkins和Docker进行自动化构建和部署,涵盖了从连接服务器到安装Jenkins和Docker的所有步骤。以下是本资源的知识点总结: 1. 连接服务器:使用ssh命令...
需要面试k8s相关岗位的小朋友来取,增加面试过关率
本文介绍VMware虚拟机下centos7操作系统中如何安装云原生 Kubernetes(k8s)集群、k8s可视化界面kuboard,以及如何利用docker容器化将springboot+vue项目在k8s集群中部署运行。
云原生大规模集群资源管理Docker+K8S 云原生大规模集群资源管理是指在云计算环境中,对大规模集群资源进行管理和调度的技术。该技术通过使用容器化技术(如Docker)和集群管理技术(如Kubernetes),实现了资源的...
云原生相关资料,包括docker和k8s
Docker和Kubernetes(简称K8s)是目前业界广泛使用的容器化技术和容器编排平台。Docker提供了一个轻量级的虚拟化解决方案,而Kubernetes则用于管理和自动化容器的部署、扩展和操作。本内容将对Docker和Kubernetes的...
本文介绍VMware虚拟机下centos7操作系统中如何安装云原生 Kubernetes(k8s)集群、k8s可视化界面kuboard,以及如何利用docker容器化将springboot+vue项目在k8s集群中部署运行。
之前自己的项目开发就搭了个cicd的环境,那时候是在本就...jenkins+dockerregistry+docker 见之前的笔记 总的差不多这样:之后对kubernetes的接触后,就在之前的基础上加入kubernetes,其实也就是在服务器拉取镜像docker
云原生技术架构设计与实践涉及到多个层面,包括但不限于云原生12军规、企业级云原生应用、Kubernetes(K8S)、DevOps等关键元素。 云原生12军规是指导云原生应用开发的基本准则,它们包括: 1. 显示声明依赖关系,...
云原生是一种基于云计算技术的软件开发和部署模式,旨在提升应用程序的可靠性、可扩展性和敏捷性。它涵盖了一系列工具、平台和最佳实践,如DevOps、容器化(Docker)、容器编排(Kubernetes)等,以帮助开发团队更...
CNCF × Alibaba云原生技术公开课-基础-测试题及答案
k8s架构图整体框架知识合集 k8s架构图整体框架知识合集是对kubernetes架构的深入剖析和总结,本文对k8s的架构、设计、实现原理、存储、网络、调度、监控、...k8s是云原生架构的一部分,负责云原生应用的管理和调度。
云原生Kubernetes全栈架构师实战 云原生Kubernetes全栈架构师实战是指通过Kubernetes构建高效、可扩展的云原生应用,并成为全栈架构师。为了达到这个目标,需要了解Kubernetes的核心概念、安装和配置、核心组件等。...
在这个企业全面追逐云原生的时代,相信K8s/Docker很快就会成为每个技术从业者必备的基础知识。 技术的发展和演进是不可逆的!早一点掌握K8s/Docker,就能先人一步抓住这波技术红利!毕竟云原生相关岗位是出了名的高...
本篇文章将深入探讨Kubernetes(K8s)在云原生部署中间件时的关键知识点。 首先,Kubernetes是Google开源的容器编排系统,它允许开发者和运维人员在集群中高效地管理和调度Docker等容器化的应用。在云原生中间件...
Kubernetes(K8s)作为容器编排的领导者,已经成为云原生架构的基石。它提供声明式API和基于控制器的架构,不仅可以管理容器,还能扩展到虚拟机、大数据、机器学习等多种工作负载。Kubernetes的普及推动了周边生态...
【标题】"k8s-fordocker-desktop-v1.29.1" 是一个专为 Docker Desktop 用户设计的 Kubernetes(k8s)环境版本,版本号为 v1.29.1。这个软件包旨在帮助Windows用户在本地环境中便捷地搭建和管理Kubernetes集群。 ...
在构建K8S驱动的云原生基础设施时,有两种主要的技术方案: 1. 裸机K8S:直接在物理服务器上部署K8S集群,提供高性能的容器服务。这种模式适合大规模、高性能的应用场景,但可能在安全性、资源利用率和硬件绑定性...