#知识迎虎年，开挂一整年#
master-01、master-02、master-03
由于haproxy部署在master节点，为避免与k8s的6443端口冲突，修改端口为9443。（如果为阿里云服务器，则可以直接使用SLB去做负载及高可用）
master-01、master-02、master-03
注意事项：
（1）主从节点需修改配置
（2）注意防火墙导致keepalive脑裂
方式一：停止iptables
方式二：开放策略
配置位置：
所有节点
配置位置：
所有节点
临时关闭
永久关闭
所有节点
查看br_netfilter模块
临时新增
永久新增
配置位置：
所有节点
配置：
加载使配置生效
配置位置：
所有节点
配置：
安装ipvs基础软件包：
linux内核开启ipvs支持：
查看是否开启了ipvs支持：
配置位置： 所有节点
查看版本
安装依赖
安装docker
由于初始化k8s从国外拉取镜像，因此可以使用阿里云镜像加速服务
修改daemonjson，新增‘”exec-opts”: [“nativecgroupdriver=systemd”’
安装位置： 所有节点
注释
*** 作位置： 所有节点
设置命令补全
*** 作位置： 所有节点
查看下载
生成初始化配置文件
修改配置文件
初始化
*** 作位置： 随便某个master节点即可
附：单个master初始化不用带下面参数
输出结果：
*** 作位置： 初始化所在master节点
生成免密钥登录
从初始化执行的节点，同步证书到其它节点
同步脚本：
同步证书到其它master节点：
*** 作位置： 其它master节点
*** 作位置： server节点
由于未添加网络组件，因此node节点的状态为 NotRready
背景： 由于coreDNS容器启动失败，看日志：
版本下载地址： >openstack 的软路由，虚拟机port已经在用internal port来接入ovs bridge，而且在性能上确实比veth-pair有提升
ovs-internal-port 111-114Gb/s (1 process) 129-133Gb/s (4 process)
veth-pair-device 108-110Gb/s (1 process) 118-122Gb/s (4 process)
但是k8s获取pod ip的方式就是通过 eth0来获取的，这是一个硬编码。
这样就要求pod内部必须要有一个eth0网卡。
为了使用internal port，
可以先创建port，接入到br-int，（不同pod使用不同的port 名）
然后将该port设备，放入pod ns内部，并进行重命名。
那么问题来了，当创建新的port的时候，或者重启openvswitch。
已经配置好的port就会从pod ns内部移出。 这样就会导致网络问题。
如果不这样做，就需要采用两个网卡的方案，用原生port名直接放进去，配置好ip，然后弄一个dummy eth0网卡，也配上ip。
但是这个逻辑又过于复杂，pod内部多网卡也不够简洁。
结论： ovs 对internal 网卡的重命名支持的不够好。
><img src=">一、什么是k8s，k8s都有什么功能？
k8s是一个docker容器管理工具
二、k8s的核心功能
k8s最适合跑微服务架构
创建一个rc yaml文件
升级 kubectl rolling-update nginx -f nginx-rc115yaml --update-period=10s
这个是rc的资源升级命令 --update-period=10s这个是10秒更新一个pod资源
回滚 kubectl rolling-update nginx2 -f nginx-rcyaml --update-period=1s
这个是回滚的命令，如果升级的新版本有问题就马上回滚到上个稳定的版本中
service帮助pod暴露端口
创建一个service
修改nodePort范围
service默认使用iptables来实现负载均衡, k8s 18新版本中推荐使用lvs(四层负载均衡)
创建deployment
kubeadm安装k8s113 - 技术之路
namespace做资源隔离
pv: persistent volume 全局的资源 pv，node
pvc: persistent volume claim 局部的资源（namespace）pod，rc，svc
上传yaml配置文件,创建pv和pvc
file:///F:/%E6%96%B0%E5%BB%BA%E6%96%87%E4%BB%B6%E5%A4%B9/%E4%BA%91%E8%AE%A1%E7%AE%97/k8sday03/k8s%E8%AF%BE%E7%A8%8Bday3pdf
Kubernetes是如今IT领域最火热的关键字，本文回顾Kubernetes的历史，介绍Kubernetes的基础概念，并和大家更为熟悉的虚拟化技术作类比加深对Kubernetes的理解，同时分析Kubernetes的优势劣势，最后展望未来。
有人认为自动化，云计算和人工智能是第四次工业革命。如果你开始感受到IT领域自动化率的飙升，特别是在应用程序部署和管理领域（我觉得还不是无缝的自插拔式），那么不用太过惊讶。几年前，Google就正式启动了名为Kubernetes的项目，也就是现在广为人知的k8s。Kubernetes是开源的容器集群管理器，意图成为能够在容器领域自治化部署以及扩展应用程序的平台。
Kubernetes是一个可移植的，可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。它拥有一个庞大且快速增长的生态系统。Kubernetes的服务，支持和工具广泛可用。
Kubernetes这个名字起源于希腊语，意思是舵手或飞行员。Google在2014年开源了Kubernetes项目。Kubernetes将 超过15年的Google 在大规模生产工作负载方面 的经验 与社区中最好的想法和实践相结合。
让我们回顾一下为什么Kubernetes如此有用。
传统部署时代： 早期，组织在物理服务器上运行应用程序。无法为物理服务器中的应用程序定义资源边界，这会导致资源分配问题。例如，如果在物理服务器上运行多个应用程序，则可能会出现一个应用程序占用大部分资源的情况，结果，其他应用程序的性能将下降。解决方案是在不同的物理服务器上运行每个应用程序。但这并没有随着资源利用不足而扩展，并且组织维护许多物理服务器的成本很高。
虚拟化部署时代： 作为解决方案，引入了虚拟化。它允许您在单个物理服务器的CPU上运行多个虚拟机（VM）。虚拟化允许在VM之间隔离应用程序，并提供安全级别，因为一个应用程序的信息不能被另一应用程序自由访问。
虚拟化可以更好地利用物理服务器中的资源，并可以实现更好的可伸缩性，因为可以轻松地添加或更新应用程序，降低硬件成本等等。借助虚拟化，您可以将一组物理资源呈现为一组一次性虚拟机。
每个VM都是一台完整的计算机，在虚拟化硬件之上运行所有组件，包括其自己的 *** 作系统。
容器部署时代： 容器类似于VM，但是它们具有轻松的隔离属性，可以在应用程序之间共享 *** 作系统（OS）。因此，容器被认为是轻质的。与VM相似，容器具有自己的文件系统，CPU，内存，进程空间等。由于它们与基础架构分离，因此可以跨云和OS分发进行移植。
容器之所以受欢迎，是因为它们提供了额外的好处，例如：
容器是捆绑和运行应用程序的好方法。在生产环境中，您需要管理运行应用程序的容器，并确保没有停机时间。例如，如果一个容器发生故障，则需要启动另一个容器。如果此行为由系统处理，会不会更容易？
这就是Kubernetes的救援方法！Kubernetes为您提供了一个可d性运行分布式系统的框架。它负责应用程序的扩展和故障转移，提供部署模式等。例如，Kubernetes可以轻松管理系统的Canary部署。
Kubernetes为您提供：
Kubernetes不是一个传统的，包罗万象的PaaS（平台即服务）系统。由于Kubernetes在容器级别而非硬件级别运行，因此它提供了PaaS产品共有的一些普遍适用的功能，例如部署，扩展，负载平衡，并允许用户集成其日志记录，监视和警报解决方案。但是，Kubernetes并不是单片的，这些默认解决方案是可选的和可插入的。Kubernetes提供了构建开发人员平台的基础，但是在重要的地方保留了用户的选择和灵活性。
Kubernetes：
在深入研究Kubernetes之前，要认识到如果没有容器的出现，Kubernetes也不会存在。从高层看，容器看上去像虚拟机，但是最大的区别是容器和其他容器共享主机系统的内核。这是最主要的差异要素，因为容器共享物理主机的OS，所以它们很容易移动。用户也可以在同一台主机上启动比VM数量多得多的容器，因为它们共享内核，库和二进制文件。比如，一个VM的大小大概是20GB，而运行着相同应用程序的容器大概只有200MB。
容器（无论是Docker还是CoreOS的rkt）允许开发人员无缝地关注于应用程序的运行时。基础架构的问题会影响到脆弱的应用程序开发的日子一去不复返了。使用容器，开发人员仅仅需要考虑如何恰当地扩展，部署以及管理他们新开发的应用程序，但是现有的容器方案并不能在跨多节点的环境里自己管理，调度以及部署容器。
在容器化的世界里，Kubernetes是环境的管理和部署引擎。使用Kubernetes的最基本功能，用户就可以轻松地在物理硬件或者虚拟机上调度并且运行应用程序。Kubernetes的更多高级用法让开发人员可以彻底摆脱主机为中心的世界，而进入容器为中心的环境里。
使用Kubernetes很容易。可以使用REST API来 *** 作Kubernetes所包含的主要组件 。Kubernetes的定位是平台，但是它包含多个组件，每个都有各自的角色。Master是Kubernetes集群里的控制服务（也称为control plane），Master很重要，因为它会API调用和其交互的其他组件。集群单元管理发生在Master里，调度服务也在这里。
Kubernetes架构介绍，Imesh Gunaratne 。
Master之下就是Kubernetes工作单元，这里定义特定工作的实体。既然最终目标是要交付一个应用程序，那么这些单元还有更多其他的特定功能。
Pod ：最基础的单元是Pod，当指派容器时，容器实际上并不会指派到物理硬件上，相反，容器会被分配到一个Pod里。Pod通常负责托管服务于单个应用程序的容器。这意味着Pod内的所有容器都能够共享卷和IP空间，允许它们扩展为单个应用程序。
Service（服务） ：如果想要构建更为稳健的容器化策略，那么“服务”的概念就更加重要。服务的功能是资源均衡器，将工作负载在容器间导流。这使得后台容器可以通过单一稳定的接入点和前端应用程序通信。这个特性让使用者更易于使用并且可扩展。
Replication Controller（副本控制器） ：这些单元的目的是确保在某个时间点，有所需数量的特定容器在运行。比如说突然某个内核出错了，导致某个容器（多个容器组内的）崩溃了，那么RC的责任是新启动一个副本Pod，直至之前的Pod在重启后恢复为止。一旦之前的Pod启动并且再次运行了，RC就会杀死副本Pod。
Label（标签） ：虽然标签并不是一种工作单元，但是它起着至关重要的组织作用。标签的功能是组命名，这样用户可以针对一组单元做 *** 作。这是用户组织容器环境的方式。
在最基础的级别上，这些是组成Kubernetes平台的实体。
想一想我们现在都很熟悉的技术，通过虚拟化类比一下Kubernetes。
Kubernetes的Master和VMware的vCenter类似。Master知道集群里的所有节点，以及所有节点的容量。而且，Master对Pod的调度及放置，类似于vCenter如何在vSphere的主机上部署VM。Pod的功能和vApp很类似，因为它们都在一个网络里托管多个容器。容器类似VM，因为它们之前都是互相隔离的，除非它们被指定特定的网络路径。最后，Replication Controller类似于HA，因为RC持续监控环境，确保正确数量的Pod在运行，如果数量少于预期，就会调度一个新的实例。
虽然Kubernetes并不是市场里唯一的容器管理平台（还有Docker Swarm和Mesos），但是它更受欢迎。为什么呢？从高层看，Kubernetes正获得关注，因为它提供了这样一个平台，容器化的应用程序可以只编写一次，就能够在所有类型的云供应商以及私有云上运行，无论底层使用的是哪种基础架构。而且，Kubernetes还在发展，让开发人员能够在Kubernetes上运行任意适合的应用程序。Sam Ghods，Box的联合创始人认为只要是能运行的二进制文件，就可以运行在Kubernetes上。
使用Kubernetes，开发人员可以快速部署应用程序，而无需担心传统平台上的诸多风险（想想跨多OS环境的垂直扩展），可以随时扩展应用程序，并且更好地分配资源。
硬件使用量的下降是使用Kubernetes带来的另一个好处。一些公司报告由于容器的轻量天性，以及能够快速杀死不需要的实体（和传统架构相比），硬件使用量减少了40-50%。eBay是Kubernetes的支持者和用户，声称自从他们切换了平台之后，看到了服务器上[overhead的急剧降低]
最后，Kubernetes最大的不同之处并非和技术相关，而是促成各种方案的社区。Google将其发布为开源项目，吸引了1000+的社区贡献者，34000次commit。它的社区比Mesos的社区（次大的竞争者社区）大5倍，比所有竞争者的社区加起来都要大。
Kubernetes受到了广泛的称赞，但是它也有一些缺点。当第一次使用它做部署（大规模）时，它很复杂，并且很难搭建。它要求具有特定技能的工程师，在现在的行业里可能很难找到。
第二，Kubernetes作为容器的第三方管理系统。容器技术本身的缺陷和成长之痛会影响到Kubernetes所能够提供的服务。
Kubernetes欠缺的领域是调度器。默认的Kubernetes调度器依赖于应用程序所有者提供的分配资源的需求，而不管实时使用量。这个方案会加重每个节点上的资源分片情况。
最后，能够在容器里运行的工作负载范围将影响Kubernetes的广泛使用，但是这并非Kubernetes可以直接解决的问题。比如，很多工程师还不想把“核心”工作负载放到容器里，因为它可能会崩溃，而容器从设计上就不是为了存储数据的。常见的实践是只在容器里运行那些崩溃后也不会导致下线时间的应用程序。
即使有这些不足，也并没有阻止Goldman Sachs，Box，SAP以及The New York Times这样的公司引入Kubernetes平台作为其下一代数据中心计划的一部分。
应用程序是如今大多数业务的生命线。公司需要快速的部署和高质量的应用程序。这些需求正是开发人员转向容器的原因。随着容器的发展，如果还认为Kubernetes的定位有问题那就难免有些愚蠢了。Kubernetes平台有很多的可能性，但是规模大了的话它也很难管理。最初的搭建和在生产环境上大规模运行Kubernetes之间的空白是很大的。近几年里，可能会有来自于第三方的强劲挑战，来管理这些部署和工作负载。对于Kubernetes来说，不囿于已经取得的成就至关重要。如果社区能够恰当地扩展平台，那么Kubernetes的前途甚为光明。
Kubernetes借鉴了Borg的设计理念，比如Pod、Service、Labels和单Pod单IP等。Kubernetes的整体架构跟Borg非常像，如下图所示：
Kubernetes主要由以下几个核心组件组成：
除了核心组件，还有一些推荐的Add-ons：
Kubernetes Architecture
Kubernetes Master
Kubernetes Node
API对象是K8s集群中的管理 *** 作单元。K8s集群系统每支持一项新功能，引入一项新技术，一定会新引入对应的API对象，支持对该功能的管理 *** 作。例如副本集Replica Set对应的API对象是RS。
每个API对象都有3大类属性：元数据metadata、规范spec和状态status。元数据是用来标识API对象的，每个对象都至少有3个元数据：namespace，name和uid；除此以外还有各种各样的标签labels用来标识和匹配不同的对象，例如用户可以用标签env来标识区分不同的服务部署环境，分别用env=dev、env=testing、env=production来标识开发、测试、生产的不同服务。规范描述了用户期望K8s集群中的分布式系统达到的理想状态（Desired State），例如用户可以通过复制控制器Replication Controller设置期望的Pod副本数为3；status描述了系统实际当前达到的状态（Status），例如系统当前实际的Pod副本数为2；那么复制控制器当前的程序逻辑就是自动启动新的Pod，争取达到副本数为3。
K8s中所有的配置都是通过API对象的spec去设置的，也就是用户通过配置系统的理想状态来改变系统，这是k8s重要设计理念之一，即所有的 *** 作都是声明式（Declarative）的而不是命令式（Imperative）的。声明式 *** 作在分布式系统中的好处是稳定，不怕丢 *** 作或运行多次，例如设置副本数为3的 *** 作运行多次也还是一个结果，而给副本数加1的 *** 作就不是声明式的，运行多次结果就错了。
Cluster 是计算、存储和网络资源的集合，Kubernetes 利用这些资源运行各种基于容器的应用。
Master 是 Cluster 的大脑，它的主要职责是调度，即决定将应用放在哪里运行。Master 运行 Linux *** 作系统，可以是物理机或者虚拟机。为了实现高可用，可以运行多个 Master。
Node 的职责是运行容器应用。Node 由 Master 管理，Node 负责监控并汇报容器的状态，并根据 Master 的要求管理容器的生命周期。Node 运行在 Linux *** 作系统，可以是物理机或者是虚拟机。
Pod 是 Kubernetes 的最小工作单元。每个 Pod 包含一个或多个容器。Pod 中的容器会作为一个整体被 Master 调度到一个 Node 上运行。
Kubernetes 引入 Pod 主要基于下面两个目的：
Kubernetes 通常不会直接创建 Pod，而是通过 Controller 来管理 Pod 的。Controller 中定义了 Pod 的部署特性，比如有几个副本，在什么样的 Node 上运行等。为了满足不同的业务场景，Kubernetes 提供了多种 Controller，包括 Deployment、ReplicaSet、DaemonSet、StatefuleSet、Job 等，我们逐一讨论。
Deployment 是最常用的 Controller，比如前面在线教程中就是通过创建 Deployment 来部署应用的。Deployment 可以管理 Pod 的多个副本，并确保 Pod 按照期望的状态运行。
ReplicaSet 实现了 Pod 的多副本管理。使用 Deployment 时会自动创建 ReplicaSet，也就是说 Deployment 是通过 ReplicaSet 来管理 Pod 的多个副本，我们通常不需要直接使用 ReplicaSet。
DaemonSet 用于每个 Node 最多只运行一个 Pod 副本的场景。正如其名称所揭示的，DaemonSet 通常用于运行 daemon。
StatefuleSet 能够保证 Pod 的每个副本在整个生命周期中名称是不变的。而其他 Controller 不提供这个功能，当某个 Pod 发生故障需要删除并重新启动时，Pod 的名称会发生变化。同时 StatefuleSet 会保证副本按照固定的顺序启动、更新或者删除。
Job 用于运行结束就删除的应用。而其他 Controller 中的 Pod 通常是长期持续运行。
RC、RS和Deployment只是保证了支撑服务的微服务Pod的数量，但是没有解决如何访问这些服务的问题。一个Pod只是一个运行服务的实例，随时可能在一个节点上停止，在另一个节点以一个新的IP启动一个新的Pod，因此不能以确定的IP和端口号提供服务。要稳定地提供服务需要服务发现和负载均衡能力。服务发现完成的工作，是针对客户端访问的服务，找到对应的的后端服务实例。在K8s集群中，客户端需要访问的服务就是Service对象。每个Service会对应一个集群内部有效的虚拟IP，集群内部通过虚拟IP访问一个服务。在K8s集群中微服务的负载均衡是由Kube-proxy实现的。Kube-proxy是K8s集群内部的负载均衡器。它是一个分布式代理服务器，在K8s的每个节点上都有一个；这一设计体现了它的伸缩性优势，需要访问服务的节点越多，提供负载均衡能力的Kube-proxy就越多，高可用节点也随之增多。与之相比，我们平时在服务器端做个反向代理做负载均衡，还要进一步解决反向代理的负载均衡和高可用问题。
Kubernetes 运行容器（Pod）与访问容器（Pod）这两项任务分别由 Controller 和 Service 执行。
名字空间为K8s集群提供虚拟的隔离作用，K8s集群初始有两个名字空间，分别是默认名字空间default和系统名字空间kube-system，除此以外，管理员可以可以创建新的名字空间满足需要。
Kubernetes（简称k8s），是一个全新的基于容器技术的分布式架构领先方案。是Google保密已久的秘密武器--Borg的开源版本。Borg使用容器技术，管理着谷歌内部规模庞大的集群管理系统。2015年，Kubernetes和Borg论文被首次公开，世人第一次揭开了它神秘的面纱。从此，爱它的人对他爱不释手；恨它的人，额，有恨它的人吗？如果用一句话说清楚k8s的作用，那就是k8s的目的是实现资源管理的自动化，尤其是在大规模的集群中。对于运维人员，使用k8s会显著地减少工作量，因为大部分任务k8s都会自动完成。对于开发来说，可以将更多的精力放在业务逻辑的打磨上。总之，k8s提供了强大的自动化能力，系统后期的运维难度和运维成本都 显著地降低。
1）运维难度大大降低。在一个团队中，只需要一小部分成员负责项目的部署和运维即可，其他人员可专业打磨业务逻辑。
2）k8s可以全面拥抱微服务。微服务的核心是将一个体量巨大的系统分解为很多小的互相连接的微服务，一个微服务可能由多个实例副本支撑，副本的数量可以随着系统的负荷进行调整。k8s几乎天然支持了微服务。
3）可以将系统随时整体搬迁到公有云上。目前，国内主流的几多云（华为云、阿里云、腾讯云）相继宣布支持k8s。同时由于k8s屏蔽了底层网络的细节，基于虚拟IP的设计思路，使得k8s与底层的硬件拓扑无关，可以无需改变运行期配置文件的情况下，对系统进行迁移。
4）k8s具有超强的横向扩展能力。
不积跬步，无以至千里。开始吧，搭建第一个k8s集群！
Kubernetes（k8s）是Google开源的容器集群管理系统（谷歌内部:Borg），它主要用于 容器编排 启动容器、自动化部署、扩展和管理容器应用和回收容器。k8s的目标是让部署容器化的应用简单并且高效，k8s提供了应用部署、规划、更新、维护的一种机制。
用kubernetes去管理Docker集群，既可以将Docker看成Kubernetes内部使用的低级别组件；另外，kubernetes不仅仅支持Docker还支持Rocket，这是另一种容器技术。
扩展资料：
从背景上说，Kubernetes是由Google与RedHat公司共同主导的开源“容器编排”项目，它起源于Google公司的Borg系统。
所以它在超大规模集群管理方面的经验要明显优于其他容器编排技术，加上Kubernetes在社区管理方面的民主化，使得它很快打败了Docker公司推出的容器编排解决方案(Compose+Swarm)，从而成为了容器编排领域事实上的标准。
而在功能上Kubernetes是一种综合的基于容器构建分布式系统的基础架构环境，它不仅能够实现基本的拉取用户镜像、运行容器，还可以提供路由网关、水平扩展、监控、备份、灾难恢复等一系列运维能力。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）