Kubernetes快速部署

前言

1.云平台基础概念
IaaS:基础设施服务
PaaS：平台服务
SaaS：软件服务
2.kubernetes与docker swarm对比
长期以来，Kubernetes 和 Docker Swarm被看做是vs的对手，在接下来的对比中，我们看一下它们应该在何时被使用，以及怎么一起工作的。
关于Kubernetes和Docker有无数的争论和讨论。如果你没有深入研究它们，你会认为这两种开源技术在争夺容器（container）霸权。 让我们来一看清楚，Kubernetes和Docker Swarm不是竞争对手！两者都有各自的优缺点，可以根据你应用程序的需求来选择使用。(择优选用，相互协作)
Docker是一种容器管理服务，它帮助开发人员设计应用程序，使用容器能更容易地创建、部署和运行应用程序。Docker有一个用于集群容器的内置机制，称为“集群模式”（swarm mode）。使用集群模式，你可以使用Docker引擎在多台机器上启动应用程序。
Docker Swarm是Docker自己针对Docker容器的原生集群解决方案，它的优点是紧密集成到Docker的生态系统中，并且使用自己的API。它监视跨服务器集群的容器数量，是创建集群docker应用程序的最方便的方法，不需要额外的硬件。它为Dockerized应用程序提供了一个小型但有用的编排系统。

使用Docker Swarm的优点

1. 更快的运行速度
2. 完备的相关技术文档（英文文档的话Docker Swarm和Kubernetes都比较完备）
3. 快速简单的配置
4. 确保程序独立（容器间低耦合）
5. 版本控制与组件重用
   以更快的速度运行： 当您使用虚拟环境时，您可能已经意识到它需要很长时间，并且包含了启动和启动您想要运行的应用程序的冗长过程。对于Docker Swarm来说，这不再是一个问题。Docker Swarm不需要启动一个完整的虚拟机，就可以让应用程序在虚拟和软件定义的环境中快速运行，并有助于DevOps的实现。
   文档提供了所有的信息： Docker团队在文档方面非常突出! Docker正在快速发展，并且非常受欢迎。如果平台的一个版本在短时间间隔内发布，有些平台可能不维护文档。但是Docker Swarm从不这样，如果一些信息只适用于Docker Swarm的特定版本，那么相应文档将确保更新了所有信息。
   提供简单快速的配置： Docker Swarm的一个主要优点是它简化了问题。Docker Swarm使用户可以自己配置，将其放入代码中并轻松部署。由于Docker Swarm可以在各种环境中使用，因此需求不受应用程序环境的约束。
   确保应用程序是隔离的：Docker Swarm负责将每个容器与其他容器隔离，并拥有自己的资源。你可以部署各种容器，以便在不同的堆栈中运行单独的应用程序。除此之外，Docker Swarm将在每个应用程序在自己的容器上运行时清除应用程序的删除。如果不再需要应用程序，可以删除它的容器。它不会在您的主机OS上留下任何临时文件或配置文件。
   版本控制和组件重用：使用Docker Swarm，您可以跟踪容器的连续版本、检查差异或回滚到前面的版本。容器重用来自前一层的组件，这使得它们非常轻量级。

使用Docker Swarm的缺点

1. 跨平台支持效果差（现在有改善，以前Windows支持比较差 ）。
2. 不提供存储选项，存储类型少。
3. 监控信息不足。
   Docker依赖于平台： Docker Swarm是一个为Linux设计的平台。虽然Docker支持Windows和Mac OS X，但它使用虚拟机在非linux平台上运行。设计为在Windows上的Docker容器中运行的应用程序不能在Linux上运行，反之亦然。
   不提供存储选项：Docker Swarm不提供将容器连接到存储的简便方法，这是主要缺点之一。它的数据量需要对主机和手动配置进行大量的改进。如果你想要Docker Swarm解决存储问题，也能办到，但是方式并不高效，且这种方式对用户并不友好。
   监控不良：Docker Swarm提供关于容器的基本信息，如果您正在寻找基本的监控解决方案，那么使用Stats命令就足够了。如果您正在寻找先进的监控，那么Docker集群不是好的选择。虽然有像CAdvisor这样的第三方工具可以提供更多的监控，但是使用Docker本身实时收集更多关于容器的数据是不可行的。

为了避免这些不足，可以使用Kubernetes

自动化容器部署、扩展和管理平台
Automated Container Deployment, Scaling and Management Platform
当在多台机器上的多个容器中使用不同组件开发应用程序时，需要一个工具来管理和协调容器。这只有在Kubernetes的帮助下才可行。
Kubernetes是一个用于在集群环境中管理容器化应用程序的开源系统。以正确的方式使用Kubernetes可以帮助DevOps作为一个服务团队自动扩展应用程序，并在零停机的情况下进行更新。
使用Kubernetes的优点
1）它的速度很快：在不停机的情况下持续部署新功能时，Kubernetes是一个完美的选择。Kubernetes的目标是以恒定的正常运行时间更新应用程序。它的速度通过您每小时可以运送的许多功能来衡量，同时保持可用的服务。
2）遵循不可变基础架构的原则: 在传统的方法中，如果多个更新出现错误，您没有任何关于部署了多少个更新以及发生错误的时间点的记录。在不可变的基础架构中，如果想要更新任何应用程序，需要使用新标记构建容器映像并部署它，用旧映像版本销毁旧容器。这样，你就会有一个记录，并了解你做了什么，万一有什么错误;您可以轻松地回滚到前面的映像。
3）提供声明式配置: 用户可以知道系统应该处于什么状态以避免错误。源代码控制、单元测试等传统工具不能与命令式配置一起使用，但可以与声明式配置一起使用。
4）大规模部署和更新软件：由于Kubernetes具有不可变的声明性，因此扩展很容易。Kubernetes提供了一些用于扩展目的的有用功能：
a）水平基础架构扩展：在单个服务器级别执行操作以应用水平扩展。可以毫不费力地添加或分离atest服务器。
b）自动扩展：根据CPU资源或其他应用程序指标的使用情况，您可以更改正在运行的容器数
c）手动扩展：您可以通过命令或界面手动扩展正在运行的容器的数量
d）复制控制器：复制控制器确保集群在运行状态下具有指定数量的等效pod。如果存在太多pod，则复制控制器可以删除额外的pod，反之亦然。
处理应用程序的可用性：Kubernetes检查节点和容器的运行状况，并在由于错误导致的盒中崩溃时提供自我修复和自动替换。此外，它在多个pod之间分配负载，以便在意外流量期间快速平衡资源。
存储卷: 在Kubernetes中，数据是在容器之间共享的，但是如果pod被杀死，则自动删除卷。此外，数据是远程存储的，因此如果将pod移动到另一个节点，数据将一直保留，直到用户删除它。
使用Kubernetes的缺点
1）初始进程需要时间：当创建一个新进程时，您必须等待应用程序启动，然后用户才能使用它。如果您要迁移到Kubernetes，则需要对代码库进行修改，以提高启动流程的效率，这样用户就不会有不好的体验。
2）迁移到无状态需要做很多工作： 如果您的应用程序是集群的或无状态的，那么将不会配置额外的pod，并且必须重新处理应用程序中的配置。
3）安装过程非常单调乏味：如果不使用Azure、谷歌或Amazon等云提供商，就很难在集群上设置Kubernetes。
Kubernetes vs. Docker Swarm：快速摘要

image.png

Docker和Kubernetes选型

Docker和Kubernetes是不同的，但不是竞争对手，准确的说两者是相辅相成，互为补充，适用的场景不一样。
正如前面所讨论的，Kubernetes和Docker都在不同的级别上工作，但都可以一起使用。
Kubernetes可以集成Docker引擎来执行Docker容器的调度和执行。由于Docker和Kubernetes都是容
器编排器，所以它们都可以帮助管理容器的数量，还可以帮助DevOps实现。两者都可以自动化运行容
器化的基础架构中涉及的大部分任务，并且都是开源软件项目，由Apache License 2.0管理。除此之
外，两者都使用YAML格式的文件来控制工具如何编排容器集群。
当两者同时使用时，Docker和Kubernetes都是部署现代云架构的最佳工具。随着Docker Swarm的豁免，Kubernetes和Docker都相互补充。
Kubernetes使用Docker作为主要的容器引擎解决方案，Docker最近宣布它可以支持Kubernetes作为其企业版的编排层，除此之外，Docker还批准了经过认证的Kubernetes程序，该程序可确保所有Kubernetes API按预期运行。Kubernetes使用Docker Enterprise的功能，如安全映像管理，其中Docker EE提供映像扫描，以确保容器中使用的映像是否存在问题。
另一个是安全自动化，其中组织可以消除低效率，例如扫描映像是否存在漏洞。

Kubernetes或Docker：哪个是完美的选择？

如果使用Kubernetes：
您正在寻找成熟的部署和监控选项
您正在寻找快速可靠的响应时间
您正在寻求开发复杂的应用程序，并且需要高资源计算而不受限制
你有一个非常大的集群
如果使用Docker：
您希望在不花费太多时间进行配置和安装的情况下启动工具
您正在寻找开发一个基本和标准的应用程序，它足够使用默认的docker镜像
在不同的操作系统上测试和运行相同的应用程序对您来说不是问题
您需要zdocker API经验和兼容性。

Kubernetes和Docker是朋友

最后的想法：Kubernetes和Docker是朋友，无论你选择Kubernetes还是Docker，两者都被认为是最好的，并且有相当大的差异。在这两者之间做出选择的最好方法可能是考虑哪一个您已经比较熟悉，或者哪一个适合您现有的软件堆栈。
如果您需要开发复杂的应用程序，请使用Kubernetes，如果您希望开发小型应用程序，请使用Docker Swarm。此外，选择正确的项目是一项非常全面的任务，完全取决于您的项目需求和目标受众。
k8s 集群快速部署
kubernetes官网地址：国外网站，访问速度较慢。

https://kubernetes.io/

kubernets中文社区地址：

https://www.kubernetes.org.cn/

k8s集群部署方式：

1. 使用minikube安装单节点集群，用于测试
2. 采用工具kubeadm
3. 使用kubespray，google官方提供的工具。
4. 全手动：二进制方式安装
5. 全自动安装：rancher 、kubesphere
   快速部署一个 Kubernetes, 即拥有了一个完整的集群。忽略三大步骤
6. centos7.7操作系统配置
7. k8s集群镜像下载

8. k8s集群网络配置

   
   image.png
   

   初始化k8s集群

kubeadm init --apiserver-advertise-address=192.168.198.156 --kubernetes- 
version v1.17.5 --service-cidr=10.1.0.0/16 --pod-network-cidr=10.81.0.0/16

mkdir -p $HOME/.kube 
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config 
sudo chown $(id -u):$(id -g) $HOME/.kube/config

kubeadm join 192.168.198.156:6443 --token 8ic4bd.ns2wgycdqx5ey7go \ 
--discovery-token-ca-cert-hash 
sha256:3b883e6c1f0dcb29834dd08af8eb6e105854d0a475edb3630afc4539fd4f95c8

K8S集群安全机制：
Kubernetes 作为一个分布式集群的管理工具，保证集群的安全性是其一个重要的任务。API Server 是
集群内部各个组件通信的中介，也是外部控制的入口。所以 Kubernetes 的安全机制基本就是围绕保护 API
Server 来设计的。Kubernetes 使用了认证（Authentication）、鉴权（Authorization）、准入控制（Admission Control）三步来保证API Server的安全 。
Authentication(认证)
第三方授权协议: authenticating proxy
HTTP Token 认证：通过一个 Token 来识别合法用户
HTTP Token 的认证是用一个很长的特殊编码方式的并且难以被模仿的字符串 - Token 来表达客户的一种方式。Token 是一个很长的很复杂的字符串，每一个 Token 对应一个用户名存储在 API Server能访问的文件中。当客户端发起 API 调用请求时，需要在 HTTP Header 里放入 Token HTTP Base 认证：通过 用户名+密码 的方式认证
用户名+：+密码 用 BASE64 算法进行编码后的字符串放在 HTTP Request 中的 Heather Authorization 域里发送给服务端，服务端收到后进行编码，获取用户名及密码 最严格的 HTTPS 证书认证：基于 CA 根证书签名的客户端身份认证方式

1. HTTPS 证书认证： 采用双向加密认证方式

   
   image.png
2. 证书颁发 ：
   手动签发：通过 k8s 集群的跟 ca 进行签发 HTTPS 证书
   自动签发：kubelet 首次访问 API Server 时，使用 token 做认证，通过后，Controller Manager 会为kubelet 生成一个证书，以后的访问都是用证书做认证了
3. 安全性说明
   Controller Manager、Scheduler 与 API Server 在同一台机器，所以直接使用 API Server 的非安全端口访问， --insecure-bind-address=127.0.0.1kubectl、kubelet、kube-proxy 访问 API Server 就都需要证书进行 HTTPS 双向认证
4. kubeconfig 文件包含集群参数（CA证书、API Server地址），客户端参数（上面生成的证书和私钥），集群context 信息（集群名称、用户名）。Kubenetes 组件通过启动时指定不同的kubeconfig 文件可以切换到不同的集群