kubernetes
2020-11-15 20:23:03 0 举报AI智能生成
登录查看完整内容
k8s知识点
作者其他创作
大纲/内容
k8s
资源对象
Spec
期望的状态
Staus
观测的状态
Metadata
Labels
标识型的kv元数据
用于筛选资源
先于普通container启动执行，直到所有initcontainer执行成功后，普通container才会被启动
唯一的组合资源的方法
可以用selector来查询
Annotations
存储资源的非标识性信息
扩展资源的spec/status
OwnerReference
所有者即集合类资源
pod的集合：replicaset、statefulset
集合类资源的控制器创建了归属资源
replicaset控制器创建pod
方便反向查找创建资源的对象
方便进行级联删除
InitContainer
pod中多个initcontainer按次序依次启动执行，pod中多个普通container是并行启动
initcontainer执行成功后就结束退出了，普通容器可能会一直执行或者重启
示例
Pod
生命周期
status
Pending：Pod 的配置已经被 API Server 存储到 etcd 中，但是此Pod因为某种原因不能被创建
Running：Pod 已经被调度成功并且绑定到了某个节点上，容器创建成功并开始运行
Succeeded：Pod 都正常运行完毕并已退出，这种状态一般在一次性任务中比较常见
Faild：Pod 里至少有一个容器运行不正常（非0状态退出），需要查找Pod失败原因
Unknown：Pod 的状态不能持续的被 kubelet 汇报给 API Server，可能是主节点也 kubelet通信问题
conditions
PodScheduled Pod 是否已经被调度，即给他分配了物理节点
ContainersReady 容器是否已经处于 Ready 状态
Ready Pod 是否应 Running 并且能够对外提供服务
Initialized 是否完成了容器初始化操作
Unschedulable 可能资源不足导致调度失败
容器探针
livenessProbe
指示容器是否正在运行。如果存活探测失败，则 kubelet 会杀死容器，并且容器将受到其 重启策略 的影响。如果容器不提供存活探针，则默认状态为 Success
readinessProbe
指示容器是否准备好服务请求。如果就绪探测失败，端点控制器将从与 Pod 匹配的所有 Service 的端点中删除该 Pod 的 IP 地址。初始延迟之前的就绪状态默认为 Failure。如果容器不提供就绪探针，则默认状态为 Success
handler
ExecAction：在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
HTTPGetAction：对指定的端口和路径上的容器的 IP 地址执行 HTTP Get 请求。如果响应的状态码大于等于200 且小于 400，则诊断被认为是成功的
TCPSocketAction：对指定端口上的容器的 IP 地址进行 TCP 检查。如果端口打开，则诊断被认为是成功的。
hook
Kubernetes管理的kubelet发起的，当容器中的进程启动前或者容器中的进程终止之前运行，这是包含在容器的生命周期之中
类型
exec：执行一段命令
HTTP：发送HTTP请求
Preset
用来在 Pod 创建的时候向 Pod 中注入某些特定信息。该信息可以包括 secret、volume、volume mount 和环境变量
控制器
Deployment
操作
更新镜像
kubectl set image deployment.v1.apps.nginx-deployment nginx=nginx:1.9.1
回滚上一版本
kubectl rollout undo deployment/nginx-deployment
回滚指定版本
kubectl rollout undo deployment/nginx-deployment --to-revisions=2
查询版本
kubectl rollout history deployment/nginx-deployment
查看状态
kubectl rollout status deployment/nginx-deployment
扩缩容
kubectl scale deploy nginx-deployment --replicas=10
暂停
kubectl rollout pause deploy nginx-deployment
恢复
kubectl rollout resume deploy nginx-deployment
更新资源
管理模式
只负责管理不同版本的replicaset，由relicaset管理pod副本数
每个replicaset对应了deployment的一个版本
一个replicaset下的pod都是相同的版本
spec字段
MinReadySeconds
判断pod available的最新ready时间
revisionHistoryLimit
保留历史的数量，默认为10
paused
标识只做数量维持、不做新的发布
progressDeadlineSeconds
判断status为failed的最大时间
定义
定义一组pod的期望数量
配置pod发布方式，保证更新过程中不可用的pod数量在限定范围内
如果发布有问题，支持一键回滚
Job
创建一个或多个pod确保指定数量的pod可以成功的运行终止
跟踪pod状态，根据配置及时重试失败的pod
确定依赖关系，保证上一个任务运行完毕后再运行下一个任务
控制任务并行度，并根据配置确保pod队列大小
Job Controller负责根据配置创建pod
Job Controller跟踪job状态，根据配置及时重试pod或者继续创建
Job Controller会自动添加label来跟踪对应的pod，并根据配置并行或者串行创建pod
DaemonSet
保证集群内每一个节点运行一组相同的pod
跟踪集群节点状态，保证新加入的节点自动创建对应的pod
跟踪集群节点状态，保证移除的节点删除对应的pod
跟踪pod状态，保证每个节点pod处于运行状态
更新策略
RollingUpdate：老的pod会被先删除，然后再去创建新的pod
OnDelete：只有手动的删除某一个对应的pod，此节点才会被更新
DaemonSet Controller负责根据配置创建pod
DaemonSet Controller跟踪job状态，根据配置及时重试pod或者继续创建
DaemonSet Controller会自动添加affinity&label来跟踪对应的pod，并根据配置在每个节点或者适合的部分节点创建pod
指定节点
nodeSelector：只调度到匹配指定label的Node上
nodeAffinity：功能更丰富的Node选择器，比如支持集合操作
podAffinity：调度到满足条件的Pod所在的Node上
Service
ClusterIP
ExternalName
NodePort
LoadBalancer
StatefulSet
StatefulSet 中的 Pod 都是有序号的，从 0 开始一直到定义的 replica 数量减一
每个 Pod 都有独立的网络标识：一个 hostname、一块独立的 pvc 以及 pv 存储
扩缩容策略
OrderedReady，扩缩容就严格按照 Order 顺序来执行
Parallel，并行扩缩容，不需要等前面的 Pod 都 Ready 或者删除后再处理下一个
配置管理
可变配置
ConfigMap
大小限制1mb
pod只能引用相同namespace的ConfigMap
pod引用的ConfigMap不存在时，无法创建成功
manifest创建的static pod不能使用ConfigMap
敏感信息
Secret
采用base-64编码保存
Opaque
kubernetes.io/service-account-token
kubernetes.io/dockerconfigjson
身份认证
ServiceAccount
用于解决pod在集群中的身份认证问题
资源配置
Spec.Containers[].Resources.limits/requests
cpu 单位millicore
memory 单位Byte
ephemeral-storage（临时存储）单位Byte
服务质量分类
guaranteed
内存和cpu限制和请求必须设置，并且必须是一样的
burstable
至少有一个内存或者cpu限制和请求
besteffort
安全管控
Spec.Containers[].SecurityContext
前置检验
Spec.InitContainers
存储
本地存储
emptydir/hostpath
网路存储
in-tree：awsElaticBlockStore
out-of-tree：csi等网络存储
Projected Volume：secret/configmap
PVC与PV体系
PV、PVC
PVC 是在 K8s 中一种抽象的存储卷类型，代表了某个具体类型存储的数据卷表达
PV 在 K8s 中代表一个具体存储类型的卷，其对象中定义了具体存储类型和卷参数
关系
PVC 和 PV 总是成对出现的，PVC 必须与 PV 绑定后才能被应用（Pod）消费；
PVC 和 PV 是一一绑定关系，不存在一个 PV 被多个 PVC 绑定，或者一个 PVC 绑定多个 PV 的情况；
PVC 是应用层面的存储概念，是属于具体的名词空间的；
PV 是存储层面的存储概念，是集群级别的，不属于某个名词空间；PV 常由专门的存储运维人员负责管理；
消费关系上：Pod 消费 PVC，PVC 消费 PV，而 PV 定义了具体的存储介质
绑定规则
VolumeMode：被消费 PV 的 VolumeMode 需要和 PVC 一致；
AccessMode：被消费 PV 的 AccessMode 需要和 PVC 一致；
StorageClassName：如果 PVC 定义了此参数，PV 必须有相关的参数定义才能进行绑定；
LabelSelector：通过 label 匹配的方式从 PV 列表中选择合适的 PV 绑定；
storage：被消费 PV 的 capacity 必须大于或者等于 PVC 的存储容量需求才能被绑定
如果同时有多个 PV 满足需求，则需要从 PV 中选择一个更合适的进行绑定；通常选择容量最小的，如果容量最小的也有多个，则随机选择。 如果没有满足上述需求的 PV 存储，则 PVC 会处于 Pending 状态，等待有合适的 PV 出现了再进行绑定
AccessModes
ReadWriteOnce 只允许单node访问
ReadOnlyMany 允许多个node只读访问
ReadWriteMany 允许多个node读写访问
PersistentVolumeReclaimPolicy
Delete VC 被删除之后，PV 也会被删除
Retain 保留之后，后面这个 PV 需要管理员来手动处理
StorageClassName
动态 Provisioning 时必须指定的一个字段，就是说我们要指定到底用哪一个模板文件来生成 PV
csi 使用存储流程
用户提交PVC，由 csi-provisioner创建存储，并生成 PV 对象，之后 PV controller 将 PVC 及生成的 PV 对象做 bound
户在提交 pod yaml 的时候，首先会被调度选中某一个合适的 node，等 pod 的运行 node 被选出来之后，会被 AD Controller watch 到 pod 选中的 node，它会去查找 pod 中使用了哪些 PV。然后它会生成一个内部的对象叫 VolumeAttachment 对象，从而去触发 csi-attacher去调用 csi-controller-server 去做真正的 attache 操作，attach 操作调到云存储厂商 OpenAPI。这个 attach 操作就是将存储 attach到 pod 将会运行的 node 上面
创建 pod 的过程中，首先要去做一个 mount，这里的 mount 操作是为了将已经 attach 到这个 node 上面那块盘，进一步 mount 到 pod 可以使用的一个具体路径，之后 kubelet 才开始创建并启动容器
静态、动态存储卷
静态：一般先由集群管理员分析集群中存储需求，并预先分配一些存储介质，同时创建对应的 PV 对象，创建好的 PV 对象等待 PVC 来消费
动态：由集群管理员配置好后端的存储池，并创建相应的模板（storageclass），等到有 PVC 需要消费 PV 的时候，根据 PVC 定义的需求，并参考 storageclass 的存储细节，由 Provisioner 插件动态创建一个 PV
动态创建流程
当用户声明一个 PVC 时，当 PVC 在集群中找不到匹配的 PV
PVC根据 StorageClassName 的定义触发相应的 Provisioner 插件创建合适的 PV
PV 创建完成后，Provisioner 实现与 PVC 的绑定
应用监控
健康状态
探测方式
httpGet
Exec
tcpSocket
探测结果
Success
Failure
Unknown
重启策略
Always
OnFailure
Never
其他参数
initialDelaySeconds 延迟多久检查
periodSeconds 检查间隔
timeoutSeconds 探测超时
successThreashold 探测失败后再次判断成功的阈值
failureThreshold 探测失败的重试次数
Liveness
判断容器是否存活，pod是否为running
检测失败会杀掉pod，并根据配置的策略判断是否重启
支持重新拉起的应用
Readiness
判断容器是否启动完成，pod是否为ready
检测失败会将pod从endpoint中移除
启动后无法立即对外服务的应用
资源监控
性能监控
安全监控
事件监控
容器网络
方案划分
Underlay
它与 Host 网络是同层的，从外在可见的一个特征就是它是不是使用了 Host 网络同样的网段、输入输出基础设备、容器的 IP 地址是不是需要与 Host 网络取得协同（来自同一个中心分配或统一划分）
Overlay
它不需要从 Host 网络的 IPM 的管理的组件去申请 IP，一般来说，它只需要跟 Host 网络不冲突，这个 IP 可以自由分配的
方案实现
flannel
backend
用户态的 udp，这种是最早期的实现；
内核的 Vxlan，Vxlan 的性能会比较好一点，但是它对内核的版本是有要求的，需要内核支持 Vxlan 的特性功能；
如果你的集群规模不够大，又处于同一个二层域，也可以选择采用 host-gw 的方式。这种方式的 backend 基本上是由一段广播路由规则来启动的，性能比较高。
Network Policy
采用各种选择器（标签或 namespace），找到一组 pod，或者找到相当于通讯的两端，然后通过流的特征描述来决定它们之间是不是可以联通，可以理解为一个白名单的机制
使用前提
apiserver开启extensions/v1beta1/networkpolicies
我们选用的网络插件需要支持 Network Policy，入Calico、Weave Net
CNI
配置流程
在每个结点上配置 CNI 配置文件 (/etc/cni/net.d/xxnet.conf)，其中 xxnet.conf 是某一个网络配置文件的名称
安装 CNI 配置文件中所对应的二进制插件
在这个节点上创建 Pod 之后，再由 CNI 插件进入 Pod 的网络空间去配置 Pod 的网络
模式
典型特征是容器独立于主机的IP段，这个IP段进行跨主机网络通信时是通过在主机之间创建隧道的方式，将整个容器网段的包全都封装成底层的物理网络中主机之间的包。该方式的好处在于它不依赖于底层网络
路由模式
主机和容器也分属不同的网段，它与 Overlay 模式的主要区别在于它的跨主机通信是通过路由打通，无需在不同主机之间做一个隧道封包。但路由打通就需要部分依赖于底层网络，比如说要求底层网络有二层可达的一个能力
容器和宿主机位于同一层网络，两者拥有相同的地位。容器之间网络的打通主要依靠于底层网络。因此该模式是强依赖于底层能力的
评估
环境限制
公有云环境也是虚拟化，因此底层限制也会较多。但每个公有云都会考虑适配容器，提升容器的性能，因此每家公有云可能都提供了一些 API 去配置一些额外的网卡或者路由这种能力。在公有云上，我们要尽量选择公有云厂商提供的 CNI 插件以达到兼容性和性能上的最优。比如 Aliyun 就提供了一个高性能的 Terway 插件
功能需求
安全需求
是否需要集群外的资源与集群内的资源互联互通
可以选择 Underlay 的网络，比如 sriov 这种就是 Pod 和以前的虚拟机或者物理机在同一层。我们也可以使用 calico-bgp，此时它们虽然不在同一网段，但可以通过它去跟原有的路由器做一些 BGP 路由的一个发布，这样也可以打通虚拟机与容器
K8s 的服务发现与负载均衡的能力
很多 Underlay 模式的插件，在 Pod 中的网卡是直接用的 Underlay 的硬件，或者通过硬件虚拟化插到容器中的，这个时候它的流量无法走到宿主机所在的命名空间，因此也无法应用 kube-proxy 在宿主机配置的规则
性能需求
Pod 的创建速度
需要紧急大规模扩容时，Overlay 和路由模式创建速度是很快的，因为它是在机器里面又做了虚拟化，所以只需要调用内核接口就可以完成这些操作。但对于 Underlay 模式，由于需要创建一些底层的网络资源，所以整个 Pod 的创建速度相对会慢一些
Pod 的网络性能
Overlay 模式的性能较差，因为它在节点上又做了一层虚拟化，还需要去封包，封包又会带来一些包头的损失、CPU 的消耗等，如果大家对网络性能的要求比较高，比如说机器学习、大数据这些场景就不适合使用 Overlay 模式。这种情形下我们通常选择 Underlay 或者路由模式的 CNI 插件
CNI 插件开发
给 Pod 准备一个网卡，通常我们会用一个 “veth” 这种虚拟网卡，一端放到 Pod 的网络空间，一端放到主机的网络空间，这样就实现了 Pod 与主机这两个命名空间的打通
给 Pod 分配 IP 地址，这个 IP 地址有一个要求， IP 地址在集群里需要是唯一的。
配置 Pod 的 IP 和路由1、将分配到的 IP 地址配置给 Pod 的虚拟网卡；2、在 Pod 的网卡上配置集群网段的路由3、在宿主机上配置到 Pod 的 IP 地址的路由
给 Pod 连上网络，一般我们是在 CNI Daemon 进程中去做这些网络打通的事情。通常来说是这样一个步骤：1、 CNI 在每个节点上运行的 Daemon 进程会学习到集群所有 Pod 的 IP 地址及其所在节点信息。2、拿到 Pod 以及 Node 的相关信息之后，再去配置网络进行打通
CRI
容器运行时的操作抽象出一个接口，将 Kubelet 代码与具体的容器运行时的实现代码解耦开，只要实现了这样一套接口，就能接入到 Kubernetes 的体系中
CRD
第三方应用
OpenKruise
CloneSet
提供了更加高效、确定可控的应用管理和部署能力，支持优雅原地升级、指定删除、发布顺序可配置、并行/灰度发布等丰富的策略，可以满足更多样化的应用场景
Advanced StatefulSet
基于原生 StatefulSet 之上的增强版本，默认行为与原生完全一致，在此之外提供了原地升级、并行发布（最大不可用）、发布暂停等功能
SidecarSet
对 sidecar 容器做统一管理，在满足 selector 条件的 Pod 中注入指定的 sidecar 容器
UnitedDeployment
通过多个 subset workload 将应用部署到多个可用区
BroadcastJob
配置一个 job，在集群中所有满足条件的 Node 上都跑一个 Pod 任务
CompletionPolicy
Always 策略意味着 job 最终会完成，不管是执行成功还是失败了
ActiveDeadlineSeconds：指定一个超时时间，如果 BroadcastJob 开始运行超过了这个时间，所有还在跑着的 job 都会被停止、并标记为失败。
BackoffLimit：指定一个重试次数，超过这个次数后才标记 job 失败，默认没有限制。目前，Pod 实际的重试次数是看 Pod status 中上报所有容器的 ContainerStatus.RestartCount 重启次数。如果这个重启次数超过了 BackoffLimit，这个 job 就会被标记为失败、并把运行的 Pod 删除掉。
TTLSecondsAfterFinished 限制了 BroadcastJob 在完成之后的存活时间，默认没有限制。比如设置了 TTLSecondsAfterFinished 为 10s，那么当 job 结束后超过了 10s，控制器就会把 job 和下面的所有 Pod 删掉。
Never 策略意味着 BroadcastJob 永远都不会结束（标记为 Succeeded 或 Failed），即使当前 job 下面的 Pod 都已经执行成功了
核心功能
原地升级
原地升级是一种可以避免删除、新建 Pod 的升级镜像能力。它比原生 Deployment/StatefulSet 的重建 Pod 升级更快、更高效，并且避免对 Pod 中其他不需要更新的容器造成干扰。
Sidecar 管理
支持在一个单独的 CR 中定义 sidecar 容器，OpenKruise 能够帮你把这些 Sidecar 容器注入到所有符合条件的 Pod 中。这个过程和 Istio 的注入很相似，但是你可以管理任意你关心的 Sidecar。
跨多可用区部署
定义一个跨多个可用区的全局 workload，容器，OpenKruise 会帮你在每个可用区创建一个对应的下属 workload。你可以统一管理他们的副本数、版本、甚至针对不同可用区采用不同的发布策略。
部署
下载安装包
wget -c https://sealyun.oss-cn-beijing.aliyuncs.com/d551b0b9e67e0416d0f9dce870a16665-1.18.0/kube1.18.0.tar.gz
安装集群
sealos init --passwd 123456 \\--master 192.168.0.2 --master 192.168.0.3 --master 192.168.0.4 \\--node 192.168.0.5 \\--pkg-url /root/kube1.18.0.tar.gz \\--version v1.18.0
集群操作
增加master
sealos join --master 192.168.0.6 --master 192.168.0.7sealos join --master 192.168.0.6-192.168.0.9 # 或者多个连续IP
删除master
sealos clean --master 192.168.0.6 --master 192.168.0.7sealos clean --master 192.168.0.6-192.168.0.9 # 或者多个连续IP
增加node
sealos join --node 192.168.0.6 --node 192.168.0.7sealos join --node 192.168.0.6-192.168.0.9 # 或者多个连续IP
删除node
sealos clean --node 192.168.0.6 --node 192.168.0.7 sealos clean --node 192.168.0.6-192.168.0.9 # 或者多个连续IP
清理集群
sealos clean
觉得不错，帮忙点个赞赠人玫瑰，手留余香
自由主题
收藏
0 条评论
回复 删除
下一页
