k8s核心知识总结_业界新闻

写在前面

时间一下子到了7月份尾；整个7月份都乱糟糟的，不管怎么样，日子还是得过啊，
1、7月份核心了解个关于k8s，iceberg等相关技术，了解了相关的基础逻辑，虽然和数开主线有点偏，但是幸亏自己能够及时扭转回来
2、8月份打算正式回归flink主线任务，核心完成以下几点：redis的写入对比；思考一下未来的职业规划

PS：一场手术，似乎真的让我感觉度了个假；时刻记住工作的本质：遇到问题解决问题，不断学习重试自己

1、物理机、虚拟机、容器

虚拟化：保证主机上的空闲资源可以很好的被利用，避免资源浪费；但是计算资源、网络和I/O的损耗非常大，启动慢，Hypervisor可以理解为对虚拟机的管理；

容器：共用主机内核（Docker版本必须是宿主机的内核支持的），相比虚拟机要轻量级，docker本身是用来对容器进行管理的，容器技术是Linux提供的，容器技术：What’s a Linux container?
容器的本质是利用Linux kernel提供的隔离（namespace）和限制（CGroup）机制启动的特殊进程

注：Docker中，容器内必须运行一个前台进程，否则会默认退出

2.1、docker生命周期

容器和镜像的关系可以理解为对象和类，或者java代码和java进程

build：通过dockerfile 创建一个镜像

tag：镜像本身可以进行版本迭代

push/pull：类似git的中央仓库，可以用来提交镜像文件（包括公有和私有）

load/save：拥有本地传输镜像文件

run/commit：镜像运行一个容器实例，或者提交一个镜像文件

start/stop：运行或停止一个容器

3、kubernetes

3.1、kubernetes架构

最近初步了解了一下kubernets的相关知识，下图是对其架构进行的简单整理：
Master节点
1、API Server：提供了k8s各类资源对象（pod,RC,Service等）的增删改查及watch等HTTP Rest接口，是整个系统的数据总线和数据中心。
2、etcd：A distributed, reliable key-value store for the most critical data of a distributed system
3、Controller manager：控制不同类型的Pod符合用户定义要求；ReplicationController，控制同一类Pod精确符合用户定义要求，也支持pod更新
4、scheduler：指将 Pod 放置到合适的节点上，以便对应节点上的 Kubelet 能够运行这些 Pod

Node节点：
1、kube-proxy：责为Pod创建代理服务，从apiserver获取所有server信息，并根据server信息创建代理服务，实现server到Pod的请求路由和转发，从而实现K8s层级的虚拟转发网络。
2、kubelet：用于和master通信，并对通过和容器引擎交互，操作
3、Docker：容器引擎，用于创建容器，但是在k8s中，最小调度单位是pod（豌豆荚），你可以理解为pod是基于容器产生的；
label：格式是key-value数据，用于标记pod/资源
label selector：用于过滤符合要求的label
4、flannel：flannel介绍
CNI：容器网络接口，k8s的网络解决服务提供方选择的事flanel，必须遵循CNI（flannel支持网络配置，calico支持网络配置，网络策略）