普元云计算架构师宋潇男点评：

Kubernetes 已在容器编排之战中取胜，未来很可能会成为“多云”之上的标准层，进而为分布式系统的分发和运行带来根本性的改变，而其自身则会慢慢变得像 Linux Kernel 一样，成为一种系统底层的支撑，不再引人注目。

为什么会出现k8s？

Kubernetes开源架构的源头来自于Google生产系统中运行的内部集群管理系统Borg。Google将在Borg中的10多年经验在2014年开源出来，开启了Kubernetes热潮的端倪。同年，微软、RedHat、IBM、Docker、CoreOS、Mesosphere和Saltstack等公司相继加入Kubernetes生态圈。次年，VMware、HP、Intel等公司也相继加入。也正是在2015年，随着Kubernetes 1.0正式发布，掀开了容器编排管理一发不可收拾的大幕。 Kubernetes在这场容器编排的大角逐中，从普通选手（当时Docker是容器技术的裁判，而Docker Swarm、Apache Mesos、Google Kubernetes分别是Docker容器编排的选手）逐步变成了领跑选手，进而升级为了裁判（由Kubernetes主导容器编排，而将Docker和CoreOS的Rkt等容器技术纳入容器隔离技术的角逐中），从而在容器届一骑绝尘。

接下来我们重点看看K8S，希望给以参考借鉴！要是觉得还不错，不要吝啬你手里的赞哦！！

什么是k8s？

Kubernetes (通常称为K8s，K8s是将8个字母“ubernete”替换为“8”的缩写) 是用于自动部署、扩展和管理容器化（containerized）应用程序的开源系统。Google设计并捐赠给Cloud Native Computing Foundation（今属Linux基金会）来使用的。

它旨在提供“跨主机集群的自动部署、扩展以及运行应用程序容器的平台”。它支持一系列容器工具, 包括Docker等。CNCF于2017年宣布首批Kubernetes认证服务提供商（KCSPs），包含IBM、MIRANTIS、华为、inwinSTACK迎栈科技等服务商。

k8s能干什么？

Kubernetes可以实现在物理集群或虚拟机集群上调度和运行容器，当然它还可以做得更多。

为了充分发挥容器的优势并将传统的应用部署方式甩开，需要容器的部署与运行独立于基础设施。

然而，当特定的容器不再与特定的主机绑定时，主机为中心的基础设施也不再适用：负载均衡、自动扩展等，因此需要容器为中心的架构，这便是kubernetes所提供的。

Kubernetes满足了应用程序在生产环境中的一些通用需求，例如：

协同定位的辅助进程，利用复杂应用部署，并且还保持了单容器单应用的模型
挂载存储系统
分布式加密管理
应用健康状况检查
应用实例副本
水平自动扩展
命名与发现
负载均衡
滚动升级
资源监控
日志的获取和注入
支持自省和调试以及
认证和授权

上述功能提供了平台即服务(PaaS)的简易性以及基础设施即服务(IaaS)的灵活性，提升了跨基础设施移植的方便性。

集群

在集群管理方面，K8s将集群中的机器划分为一个Master节点和一群工作节点Node。Master节点上运行着集群管理相关的一组进程kube-apiserver、kube-controller-manager和kube-scheduler。这些进程自动化实现了整个集群的资源管理、Pod调度、弹性伸缩、安全控制、系统监控和纠错等管理功能。

K8S核心

Pod

Pod是K8s最重要也是最基础的概念！每个Pod都有一个特殊的被称为“根容器”的Pause容器，此容器与引入业务无关并且不易死亡。且以它的状态代表整个容器组的状态！Pause容器对应的镜像属于K8s平台的一部分，除了Pause容器，每个Pod还包含一个或多个用户业务容器。Pod其实有两种类型：普通的Pod及静态Pod（static Pod）,static Pod并不存放在Kubemetes的eted存储里，而是存放在某个具体的Node上的一个具体文件中，并且只在此Node上启动运行。而普通的Pod一旦被创建，就会被放入到etcd中存储，确后会被KubernetesMaster调度到某个具体的Node上并进行绑定（Binding），随后该Pod被对应的Node上的kubelet进程实例化成一组相关的Docker容器并启动起来。在默认情况下，当Pod里的某个容器停止时，Kubemetes会自动检测到这个问题并且重新启动这个Pod（重启Podel）的所有容器），如果Pod所在的Node完机，则会将这个Node上的所有Pod重新调度到其他节点上。Pod（上图绿色方框）安排在节点上，包含一组容器和卷。同一个Pod里的容器共享同一个网络命名空间，可以使用localhost互相通信。

Endpoint（Pod IP + ContainerPort） pod ip：一个Pod里多个容器共享Pod IP地址。K8s要求底层网络支持集群内任意两个Pod之间的TCP/IP直接通信，使用虚拟二层网络技术（Flannel（没有接触过），OpenvSwitch）实现。在Vmware中类似的二层交换技术是VSwitch，当然了，现在整个数据中心网络二层逐步从vSwitch—>OpenvSwitch

Lable

Lable类似Docker中的tag，一个是对“特殊”镜像、容器、卷组等各种资源做标记，一个是attach到各种诸如Node、Pod、Server、RC资源对象上。不同的是Lable是一对键值对！Lable类似Tag，可使用K8s专有的标签选择器（Label Selector）进行组合查询。

Controller

Replication Controller，简称RC，她用来干啥呢？就是通过她来实现Pod副本数量的自动控制！RC确保任意时间都有指定数量的Pod“副本”在运行。

如果为某个Pod创建了RC并且指定3个副本，它会创建3个Pod，并且持续监控它们。如果某个Pod不响应，那么Replication Controller会替换它，保持总数为3。如果之前不响应的Pod恢复了，现在就有4个Pod了，那么Replication Controller会将其中一个终止保持总数为3。如果在运行中将副本总数改为5，Replication Controller会立刻启动2个新Pod，保证总数为5。还可以按照这样的方式缩小Pod，这个特性在执行滚动升级时很有用。注意：删除RC，不会影响该RC已经创建好的Pod。在逻辑上Pod副本和RC是解耦和的！创建RC时，需要指定Pod模板（用来创建Pod副本的模板）和Label（RC需要监控的Pod标签）。由Replication Controller衍生出Deployment，与RC相似90%，目的是更好地解决Pod编排。暂时不讨论。 Horizontal Pod Autoscaler，简称HPA，Pod横向自动扩容智能控件。与RC，Deployment一样，也属于K8s的一种资源对象。她的实现原理是通过追踪分析RC控制的所有目标Pod的负载变化情况，来确定是否针对性地调整目标Pod的副本数。

Service

微服务架构中的一个“微服务”，她是正真的新娘，而之前的Pod，RC等资源对象其实都是嫁衣。

每个Pod都会被分配一个单独的IP地址，而且每个Pod都提供了一个独立的Endpoint（Pod lP + ContainerPort）以被客户端访问，现在多个Pod副本组成了一个集群来提供服务，客户端要想访问集群，一般的做法是部署一个负载均衡器（软件或硬件），为这组Pod开启一个对外的服务端口如8000端口，并且将这些Pod的Endpoint列表加入8000端口的转发列表中，客户端就可以通过负载均衡器的对外IP地址 + 服务端口来访问此服务，而客户端的请求最后会被转发到哪个Pod，则由负载均衡器的算法所决定。

K8s的server定义了一个服务的访问入口地址，前端（Pod）通过入口地址访问其背后的一组由Pod副本组成的集群实例，service与其后端Pod副本集群之间通过Label Selector 实现“无缝对接”。

可以将Server抽象成特殊的扁平的双向管道，Service借助Label Selector保证了前端容器正确可靠地指向对应的后台容器。 RC的作用保证了Service的服务能力和服务质量始终处于预期的标准。

Kubemetes也遵循了上述常规做法，运行在每个Node上的kube-proxy进程其实就是一个智能的软件负载均衡器，它负责把对Service的请求转发到后端的某个Pod实例上，并在内部实现服务的负载均衡与会话保持机制。但Kubernetes发明了一种很巧妙又影响深远的设计：Service不是共用一个负载均衡器的IP地址，而是每个Service分配了一个全局唯一的虚拟IP地址，这个虚拟IP被称为ClusterIP。这样一来，每个服务就变成了具备唯一IP地址的“通信节点”，服务调用就变成了最基础的TCP网络通信问题。

Pod的Endpoint地址会随着Pod的销毁和重新创建而发生改变，因为新Pod的IP地址与之前旧Pod的不同。而Service一旦创建，Kubemetes就会自动为它分配一个可用的Cluster IP，而且在Service的整个生命周期内，它的ClusterIP不会发生改变。于是，服务发现这个棘手的问题Kubemetes的架构里也得以轻松解决：只要用Service的Name与Service的Cluster IP地址做一个DNS域名映射即可完美解决问题。

K8S架构组件

Master(主控节点)和node(工作节点)

(1) master组件

Master指的是集群控制节点。每个K8s集群里需要有一个Ms节点负责整个集群的管理和控制。Kubernetes Master提供集群的独特视角，并且拥有一系列组件。

Kubernetes API Server（kube-apiserver），侍卫大统领！提供HTTP Rest接口的关键服务进程，是K8s里所有资源的增删改查等操作的唯一入口，也是集群控制的入口进程。API Server提供可以用来和集群交互的Rest端点。
Kubernetes Controller Master（kube-controller-manager）掌印大太监，大总管！K8s里所有资源对象的自动化控制中心。
Kubernetes Scheduler（kube-scheduler），御马间的调度室！负责资源调度（Pod调度）的进程。创建和复制Pod的Replication Controller。

(2) node组件

节点（上图橘色方框）是物理或者虚拟机器，作为Kubernetes worker，通常称为Minion。每个节点都运行如下Kubernetes关键组件。

(1) Kubelet：与Master节点协作，是主节点的代理，负责Pod对应容器的创建，启动，停止等任务。默认情况下Kubelet会向Master注册自己。Kubelet定期向主机点汇报加入集群的Node的各类信息。 (2) Kube-proxy：Kubernetes Service使用其将链接路由到Pod，作为外部负载均衡器使用，在一定数量的Pod之间均衡流量。比如，对于负载均衡Web流量很有用。 (3) Docker或Rocket：Kubernetes使用的容器技术来创建容器。

为什么要学习k8s？

利用kubernetes，你可以快速高效地响应客户如下请求：

应用程序的动态、精准部署
应用程序的动态扩展
无缝推出新功能
按需优化使用硬件资源

kubernetes是：便携的：公有云、私有云、混合云、多云可扩展的：模块化、即插即用、钩子化、组合化自动修复的：自动布局、自动重启、自动副本、自动伸缩 Kubernetes项目是2014年由Google公司启动的，Kubernetes在Google公司15年生产环境经验基础上，结合了社区的一些优秀点子和实践而构建的。

相信以上的信息也让你们了解了k8s的重要性，k8s在很多的大企业中都在应用，所以我们有必要来学习k8s技术。

之前我也找到很多的资料，但是东西都比较的零散，还需要自己去好好的整理。还有一些面试题也要好好的积累。

近日，经过一朋友的透露，Alibaba也首发了一份限量的“Java成长手册”，里面记载的知识点非常齐全，看完之后才知道，差距真的不止一点点！

手册主要是将Java程序员按照年限来进行分层，清晰的标注着Java程序员应该按照怎样的路线来提升自己，需要去学习哪些技术点。