阿里云架构师强烈推荐的K8S文档,学完晒一下自己的学习笔记

目录

读书笔记

第一章 k8s入门

第二章 实践指南

2.1 基本配置

2.4 Pod

2.4.3 静态pod

2.4.4 容器共享volume

2.4.5 pod配置管理

2.4.6 生命周期和重启策略

2.4.7 健康检查

2.4.8 Pod的调度方式

1 RC Deployment

2 DaementSet

3 Job 批处理任务调度

2.4.9 Pod的扩缩容

2.5 service

2.5.2 service的基本使用

直接使用RC创建多个副本和创建SVC提供服务的异同

直接创建RC

使用SVC

2.5.3 集群外部访问SVC或者Pod

2.5.4 搭建DNS

第三章 原理分析

3.1 API Server

3.2 Controller Manager

3.2.1 Replication Controller

3.2.2 Node Controller

3.2.3 ResourceQuota Controller

3.2.4 Namespace Controller

3.2.5 SVC Controller& Endpoint Controller

3.3 Scheduler

3.3.1 默认的调度流程如下:1&2

3.4 Kubelet

容器健康检查

资源监控

3.5 Kube-Proxy

3.6 集群安全机制

3.7 网络原理

1 k8s的网络模型

2 Docker的网络基础是什么?

3 Docker的网络模型和局限?

4 k8s的网络组件之间是如何通讯的?

容器到容器之间的通讯

Pod到Pod之间的通讯

同Node内Pod

不同Node的Pod

Pod到Service之间的通讯

集群外与内部组件之间的通讯


读书笔记

互联网编程随时代发展,现在也是开发的重中之重,没得办法,虽然身在传统crud中,那也不能不学习不是,这不,最近在看K8S的一份文档,自我感觉不错,但是出于个人的习惯,我比较习惯整理知识图谱和做笔记

下面和大家分享我的学习笔记和做的知识图谱,和大家进行交流

先展示思维导图

由于所由笔记展现较多,这里先暂时展示一部分和大家分享,若是大家还想交流,我后期会继续更新

注:有需要我的思维导图以及学习参考文档的,可以关注+转发后,私信“资料”即可获取

第一章 k8s入门

k8s是什么: 一个开源的容器集群管理平台,可提供容器集群的自动部署,扩缩容,维护等功能。分为管理节点Master和工作节点Node

核心组件

  • etcd保存了整个集群的状态;
  • apiserver提供了资源操作的唯一入口,并提供认证、授权、访问控制、API注册和发现等机制;
  • controller manager负责维护集群的状态,比如故障检测、自动扩展、滚动更新等;
  • scheduler负责资源的调度,按照预定的调度策略将Pod调度到相应的机器上;
  • kubelet负责维护容器的生命周期,同时也负责Volume(CVI)和网络(CNI)的管理;
  • Container runtime负责镜像管理以及Pod和容器的真正运行(CRI);
  • kube-proxy负责为Service提供cluster内部的服务发现和负载均衡;

分层架构:

  • 核心层:k8s最核心的功能,对外提供API构建高层应用,对内可提供插件式的应用执行环境。
  • 应用层:部署和路由
  • 管理层:策略管理,自动化管理,以及系统度量。
  • 接口层:kubectl命令行工具。
  • 生态系统:外部:日志、监控、配置管理、CI、CD等 内部:CRI、CNI、CVI、镜像仓库、Cloud Provider、集群自身的配置和管理等。

第二章 实践指南

2.1 基本配置

apiVersion : v1 用来标识版本
kind : Pod/Service 类型可选Pod Service等
metadata: name: nameSpace:
 

2.4 Pod

  • pod中的容器要求启动命令必须以前台命令作为启动命令【避免k8s 监控到pod运行结束 销毁,根据配置的RC副本数量重新启动,从而进入死循环】
  • pod 可以由一个或者多个容器组合而成。
  • pod中的多个容器只需要localhost就可以相互访问。

2.4.3 静态pod

静态pod 是由kubelet进行管理创建的只存在于特定Node上的Pod,kubelet无法对其进行静态检查,且一般只存在于kubelet所在的节点上。
且无法通过API server进行管理,也不会和ReplicationController Deployment产生关联。

创建方式: yml文件【配置文件】或者http请求

如何删除: 无法通过API server进行管理,所以Master无法对静态pod进行删除【状态更新为pending】。删除只能通过所在的node节点删除配置文件

2.4.4 容器共享volume

在同一个pod内的容器可以共享pod级别的volume

2.4.5 pod配置管理

pod可以通过k8s提供的集群化配置管理方案 configMap来实现配置信息和程序分离。

创建方式: yaml文件

2.4.6 生命周期和重启策略

生命周期 在系统内被定义为各种状态。可以分为 Pending Running Succeeded Failed Unknow

  • Pending : API Server 已经创建好Pod,但是Pod内还有一个或者多个容器的镜像没创建,包括正在下载的镜像。
  • Running : Pod内所有的容器已经创建成功,至少有一个容器处于运行,正在启动或者重启状态。
  • Succeeded : Pod内的所有容器均成功执行退出,且不会再重新启动。
  • Failed : 所有容器都已退出,至少有一个容器为退出失败状态。
  • Unknow: 无法获取到Pod的状态。

重启策略 应用于Pod内的所有容器,并由Pod所在node节点上的kubelet进行状态判断和重启。当容器异常退出或者健康检查状态失败的时候,kubelet会根据所设置的重启策略重新启动该container

  • always : 当容器失效时,由kubelet自动重启该容器。
  • OnFailure : 容器运气终止且状态码不为0的时候。
  • Never :无论状态如何都不重启该容器。

重启的间隔时间以设定的间隔时间的2n来计算,且在成功重启的10分钟后重置该时间。

不同的控制器对Pod的重启策略的要求是不一样的:

  • RC和DaemonSet: 这2类控制器要求所管理的Pod 必须设置为Always,才能保障整个k8s周期内,提供服务的副本数量是满足要求的。
  • Job: 这类控制器可根据需求灵活设定OnFailure 或者Never
  • Kubelet: 由kubelet管理的一般是静态Pod,kubelet不会对其进行健康检查,Pod失效就会进行重启。和设置的重启策略没有关联。

2.4.7 健康检查

pod的健康检查可使用2类探针: LivenessProbe 和ReadinessProbe

  • LivenessProbe :用来判断容器是否存活【running状态】若容器不处于running状态,则会有kubelet对容器根据设定的重启策略进行操作。若容器内不存在LivenessProbe探针,kubelet会认为容器的状态是succeed
  • ReadinessProbe :用来判断容器是否是ready状态【这个状态下可以正常接收请求 处理任务】若ReadinessProbe 探针检查失败,EndPoint controller 会从service的endPoint中删除包含该容器所在Pod的endPoint不让该容器对外提供服务。

LivenessProbe 探针的实现方法

  • ExecAction 在容器内执行命令若返回状态码为0 表示容器正常。
  • TcpSocketAction 成功建立Tcp连接表示状态正常。
  • HttpGetAction 对容器路径内调用httpGet方法若返回的状态码在200-400之间表示容器状态正常。

2.4.8 Pod的调度方式

1 RC

  • 1
    点赞
  • 9
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值