Micky_Yang-CSDN博客

原创 Istio的JWT认证授权

一、理解JWT　　JWT（Json Web Token）是一种多方传递可信JSON数据的方案，一个JWT token由.分隔的三部分组成：{Header}.{Payload}.{Signature}，其中Header是Base64编码的JSON数据，包含令牌类型typ、签名算法alg以及密钥ID kid等信息；Payload是需要传递的claims数据，也是Base64编码的JSON数据，其中有些字段是JWT标准已经有了的字段，如：exp、iat、iss、sub和aud等等，也可以根据需求添加自定义字段；

2021-08-15 15:17:00 1315

原创 Istio的mTLS认证

一、理解mTLS　　TLS在web端使用的非常广泛，针对传输的内容进行加密，能够有效的防止中间人攻击。双向TLS（Two way TLS/Mutual TLS，简称mTLS）的主要使用场景是在B2B和Server-toServer的场景中，以支持服务与服务之间的身份认证与授权。　　　　mTLS主要负责服务与服务之间传输层面的认证，具体实现在sidecar中，在具体进行请求时，讲经历如下过程：　　1）客户端发出的请求将被发送到客户端sidecar　　2）客户端sidecar与服务端sidecar开

2021-08-14 16:04:44 3194

原创 Istio的授权策略

一、理解授权　　为了保障集群中的服务的安全，Istio提供了一系列开箱即用的安全机制，对服务进行访问控制就是其中非常重要的一个部分，这个功能被称为授权。授权功能会按照预定义的配置针对特定的请求进行匹配，匹配成功之后会执行对应的动作，例如放行请求或者拒绝请求。　　由于作用的对象是服务，因此，授权功能主要适用于四层至七层（相比较而言，传统的防火墙主要用于二至四层），例如gRPC、HTTP、HTTPS和HTTP2以及TCP协议等等，对基于这些协议的请求进行授权检测，Istio都可以提供原生支持。　　从数据流

2021-08-07 19:11:42 2682

原创 Istio的分布式追踪Jaeger

一、认识分布式追踪　　相比传统的"巨石"应用，微服务的一个主要变化是将应用中的不同模块拆分为了独立的进程。在微服务架构下，原来进程内的方法调用成为了跨进程的远程方法调用。相对于单一进程内的方法调用而言，跨进程调用的调试和故障分析是非常困难的，难以适应传统的代码调试程序或者日志打印来对分布式的调用过程进行查看和分析。　　　　如上图右边所示，微服务架构中系统各个微服务之间存在复杂的调用关系。一个来自客户端的请求在其业务处理中经过了多个微服务进程。我们如果想要对该请求的端到端调用过程进行完整的分析，则必须将

2021-08-01 18:14:57 4506

原创 Istio的监控组件Prometheus

一、认识Prometheus　　Prometheus是一款开源的、自带时序数据库的监控告警系统。目前，Prometheus已经成为Kubernetes集群中监控告警系统的标配。Prometheus的架构如下图所示：　　　Prometheus通过规则对Kubernetes集群中的数据源做服务发现（Service Dicovery），再从数据源中抓取数据，保存在它的时序数据库TSDB中，再根据配置的告警规则，将数据推送给AlterManager服务，做告警信息的推送。同时，Prometheus中也暴露了H

2021-08-01 17:23:55 4986

原创 Istio的可视化组件Kiali

一、认识Kiali　　单体应用使用微服务架构拆分成了许多微服务的组合。服务的数量显著增加，就需要了解服务之间的通信模式，例如容错（通过超时、重试、断路等等）以及分布式跟踪，以便能够看到服务调用的去向。服务网格可在平台级别提供这些服务，并使应用程序编写者从以上繁重的通信模式中解放出来。路由决策在网格级别完成。Kiali与Istio合作，可视化服务网格拓扑、断路器和请求率等功能。Kiali还包括Jaeger Tracing，可以提供开箱即用的分布式跟踪功能。　　Kiali提供以下功能：　　　　1）服务拓扑

2021-07-31 18:30:22 5195

原创 Istio的ServiceEntry

一、理解ServiceEntry　　Istio支持对接Kubernetes、Consul等多种不同的注册中心，控制平面Pilot启动时，会从指定的注册中心获取Service Mesh集群的服务信息和实例列表，并将这些信息进行处理和转换，然后通过xDS下发给对应数据平面，保证服务之间可以互相发现并正常访问。　　同时，由于这些服务和实例信息都来源于网格内部，Istio无法从注册中心直接获取网格外的服务，导致不利于网格内部与外部服务之间的通信和流量管理。为此，Istio引入了ServiceEntry实现对外通

2021-07-31 18:05:38 4427

原创 Istio的流量镜像

一、理解流量镜像　　流量镜像（Mirroring/traffic-shadow），也叫作影子流量，是指通过一定的配置将线上的真实流量复制一份到镜像服务中去，我们通过流量镜像转发以达到在不影响线上服务的情况下对流量或请求内容做具体分析的目的，它的设计思想是只做转发而不接收响应（fire and forget）。这个功能在传统的微服务架构里是很难做到的，一方面，传统服务之间的通讯是由SDK支持的，那么对流量镜像就代表着在业务服务逻辑中有着镜像逻辑相关代码的侵入，这会影响业务服务的代码的整洁性。另一方面，流量镜

2021-07-25 17:51:13 4983

原创 Istio的故障注入

一、理解故障注入　　在一个微服务架构的系统中，为了让系统达到较高的健壮性要求，通常需要对系统做定向错误测试。比如电商中的订单系统、支付系统等若出现故障那将是非常严重的生产事故，因此必须在系统设计前期就考虑多样性的异常故障并对每一种异常设计完善的恢复策略或优雅的回退策略，尽全力规避类似事故的发生，使得当系统发生故障时依然可以正常运作。而在这个过程中，服务故障模拟一直以来是一个非常繁杂的工作，于是在这样的背景下就衍生出了故障注入技术手段，故障注入是用来模拟上游服务请求响应异常行为的一种手段，通过人为模拟上游服

2021-07-25 17:12:44 5222 3

原创 Istio的熔断

一、理解熔断　　熔断（Circuit Breaker），原是指当电流超过规定值时断开电路，进行短路保护或严重过载时的一种保护机制。后来熔断也广泛应用于金融领域，指当股指波幅达到规定的熔断点时，交易所为控制风险采取的暂停交易措施。而在软件领域，熔断则是指当服务达到系统负载阈值时，为避免整个软件系统不可用，而采取的一种主动保护措施。对于微服务系统而言，熔断尤为重要，它可以使系统在遭遇某些模块故障时，通过服务降级等方式来提高系统核心功能的可用性，得以应对来自故障、潜在峰值或其他未知网络因素的影响。二、配置熔

2021-07-24 18:55:16 4419

原创 Istio超时与重试

一、理解超时与重试　　超时的原理是，如果程序请求长时间无法返回结果，则需要设置超时机制，超过设置的时间则返回错误的信息；这样做既可以节约等待时消耗的资源，也可以避免由于级联错误引起的一系列问题。设置超时的方式也有很多种，比如通过修改代码在应用程序侧设置请求超时时间，但是这样非常的不灵活，也很容易出现遗漏的现象，而Istio则可以在基础设施层解决这一问题。　　重试的原理是，在网络环境不稳定的情况下，会出现暂时的网络不可达的现象，这时就需要重试机制，通过多次的尝试来获取正确的返回信息。　　二、配置超时

2021-07-24 18:13:14 4936 4

原创 Istio的Ingress与Egress网关

一、认识Ingress　　在Istio的流量控制中，Ingress可以理解为前端应用的一个代理网格，当被转发到代理容器的流量到达服务前，会先经过该服务的Ingress Gateway，之后；再有Ingress Gateway转发至后端的VirtualService资源对象上。　　二、Ingress实验1）部署httpbin服务➜ cat ../../samples/httpbin/httpbin.yaml # Copyright Istio Authors## Licensed und

2021-07-03 18:41:20 6327 1

原创 Istio流量控制资源对象

一、VirtualService资源　　VirtualService（虚拟服务）在增强Istio流量管理的灵活性和有效性方面发挥着至关重要的作用。Virtualservice由一组路由规则组成，用于对服务实体（在Kubernetes中对应为Pod）进行寻址。如果有流量命中了某条路有规则，就会将其发送到对应的服务或者服务的一个版本/子集。　　VirtualService描述了用户可寻址目标到网格内实际工作负载之间的映射。可寻址的目标服务使用hosts字段来指定，而网格内的实际负载由每个route配置项中d

2021-07-03 16:30:10 3769 2

原创 Istio安装与Bookinfo部署

一、下载Istio软件包➜ ~ curl -L https://istio.io/downloadIstio | sh - ➜ ~ ls -l istio-1.10.1 total 48-rw-r--r-- 1 jyy staff 11348 6 5 04:44 LICENSE-rw-r--r-- 1 jyy staff 5866 6 5 04:44 README.mddrwxr-x--- 3 jyy staff 96

2021-06-19 17:11:53 3862

原创 Service Mesh与Istio初识

一、Service Mesh介绍　　服务网格（Service Mesh）是处理服务间通信的基础设施层。它负责构成现代云原生应用程序的复杂服务拓扑来可靠的交付请求。在实践中，Service Mesh通常以轻量级网络代理阵列的形式实现，这些代理与应用程序代码部署在一起，对应用程序来说无需感知代理的存在。　　如果用一句话来解释什么是Service Mesh，可以将它比作是应用程序或者说微服务间的TCP/IP，负责服务之间的网络调用、限流、熔断和监控。对于编写应用程序来说一般无须关心TCP/IP这一层（比如说通

2021-06-13 16:35:02 3720 1

原创 Kubernetes学习之HPA控制器

一、认识HPA　　Deployment、ReplicaSet、Replication Controller或StatefulSet控制器资源管控的Pod副本数量支持手动方式的运行时调整，从而更好地匹配业务规模的实际需求。不过，手动调整的方式依赖于用户深度参与监控容器应用的资源压力并且需要计算出合理的值进行调整，存在一定的程度的滞后性。为此，Kubernetes提供了多种自动弹性伸缩（Auto Scaling）工具。具体如下：　　HPA：全称为Horizontal Pod Autoscaler，一种支持控

2020-11-22 17:00:13 949

原创 Kubernetes学习之Helm包管理器

一、认识Helm　　在之前的文章中的应用部署过程可知，在Kubernetes系统上面部署容器化应用时需要事先手动编写资源配置清单文件，而且其每一次的配置定义基本上都是硬编码。基本上无法实现复用。对于较大规模的应用场景、分发、版本控制、查找、回滚甚至是查看都将是用户的噩梦。Helm却可以大大的简化应用管理的难度。　　简单来说，Helm就是Kubernetes的应用程序包管理器，类似于Linux系统之上的yum或apt-get等。可用于实现帮助用户查找、分享及使用Kubernetes应用程序，目前的版本由C

2020-11-15 21:24:35 424

原创 Kubernetes学习之Prometheus监控

一、自定义指标　　除了资源指标之外，用户和管理员需要了解的指标数据还有很多，如Kubernetes指标、更全面的容器指标、更全面的节点资源指标及应用程序指标等等。自定义指标API运行请求任意指标，其指标API的实现要特定于相应的后端监视系统。Prometheus是第一个开发了相应适配器的监控系统，毕竟它是监控Kubernetes的第一选择。这个适用于Prometheus的Kubernetes Custom Metrics Adapter由托管在Github上的k8s-prometheus-adapter项

2020-09-26 17:59:47 641

原创 Kubernetes学习之Metrics-Server

一、资源监控　　Kubernetes有多个数据指标需要采集相关的数据，而这些指标大体上可以分为两个组成部分：监控集体本身和监控Pod对象，在集群监控层面，目标是监控整个Kubernetes集群的健康状况，包括集群中的所有工作节点是否运行正常、系统资源容量大小、每个工作节点上运行的容器化应用的数量以及整个集群的资源利用率等等，它们通常可以分为如下一些可衡量的指标。　　1）节点资源状态：这个领域的众多指标都与资源利用状况有关，主要有网络带宽、磁盘空间、CPU和内存的利用率；基于这些度量指标，管理员能够评估集

2020-09-26 16:14:15 1182

原创 Kubernetes学习之污点

一、认识污点　　污点（taints）是定义在节点之上的键值型属性数据，用于让节点拒绝将Pod调度运行于其上除非该Pod对象具有接纳节点污点的容忍度。而容忍度（tolerations）是定义在Pod对象上的键值型属性数据，用于配置其可容忍的节点污点，而且调度器仅能将Pod对象调度至其能够容忍该节点污点的节点之上，如下图所示：　　节点选择器（nodeSelector）和节点亲和性（nodeAffinity）两种调度方式都是通过在Pod对象上添加标签选择器来完成对特定类型节点标签的匹配，它们实现的是由Pod

2020-09-23 11:11:09 1517

原创 Kubernetes学习之高级调度

一、认识Kubernetes调度器　　Kubernetes系统的核心任务在于创建客户端请求创建的Pod对象并确保其以期望的状态运行。创建Pod对象时，调度器（scheduler）负责为每一个未经调度的Pod资源、基于一系列的规则集从集群中挑选出一个合适的节点来运行它，因此它也可以称作Pod调度器。调度过程中，调度器不会修改Pod资源，而是从中读取数据，并根据配置的策略挑选出最适合的节点，而后通过API调用将Pod绑定至挑选出的节点之上以完成调度过程。　　　　Kubernetes内建了适合绝大多数场景中

2020-09-20 18:11:25 466

原创 Kubernetes学习之资源限额

一、资源需求与限制　　在Kubernetes上，可由容器或Pod请求或消费的"计算资源"是指CPU和内存（RAM），这也是目前仅有的受支持的两种类型。相比较来说，CPU属于可压缩（compressible）型资源，即资源的使用额度可按需收缩，而内存（当前）则是不可压缩性资源，对其执行收缩操作可能会导致某种程度的问题。　　目前来说，资源隔离尚且属于容器级别的，CPU和内存资源的配置需要在Pod中的容器上进行，每种资源均可由"requests"属性定义其请求的确保可用值，即容器运行可能用不到这些额度的资源，

2020-09-19 20:44:10 981

原创 Kubernetes学习之RBAC

一、访问控制概述　　API Server作为Kubernetes集群系统的网关，是访问及管理资源对象的唯一入口，余下所有需要访问集群资源的组件，包括kube-controller-manager、kube-scheduler、kubelet和kube-proxy等集群基础组件、CoreDNS等集群的附加组件以及此前使用的kubelet命令等都要经由网关进行集群访问和管理。这些客户端均要经由API Server访问或改变集群状态并完成数据存储，并由它对每一次的访问请求进行合法性校验，包括用户身份鉴别、操作权

2020-09-17 20:54:46 279

原创 Kubernetes学习之StatefulSet控制器

一、认识StatefulSet控制器　　简单来说，StatefulSet控制器能够记录有状态应用的拓扑及状态，并能够在控制循环监控到某Pod的"实际状态"与用户的"期望状态"不一致时，严格按照Pod自身的程序状态属性将其予以恢复，StatefulSet（有状态副本集）能够保证由其管控的每个Pod对象都有着固定的主机名和专有存储卷，即便被重构后亦能保持不变。　　应用程序与用户、设备其他应用程序或外部组件进行通信时，根据其是否需要记录前一次或多次通信中的相关事件信息以作为下一次通信的分类标准，可以将那些需要

2020-09-11 09:53:56 310

原创 Kubernetes学习之Secret

一、认识Secret　　Secret资源的功能类似于ConfigMap，但是它专用于存放敏感数据，例如密码、数字证书、私钥、令牌和SSH key等。　　Secret对象存储数据的方式及使用方法类似于ConfigMap对象，以键值对方式存储数据，在Pod资源中通过环境变量或存储卷进行数据访问。不同的是，Secret对象仅会被分发至调用了此对象的Pod资源所在的工作节点，且只能由节点将其存储于内存中。另外，Secret对象的数据的存储及打印格式为Base64编码的字符串，因此用户在创建Secret对象时也要

2020-08-30 18:44:35 1281

原创 Kubernetes学习之ConfigMap

一、认识ConfigMap资源　　在分布式环境中，基于负载、容错等需求的考虑，几乎所有的服务器都需要在不同的机器上分别部署不止一个实例。随着程序功能的日益复杂，同时配置文件的修改频率通常远远大于代码本身，这种情况下，有时仅仅是一个配置内容的修改，就不得不重新进行代码提交、打包、分发上线的流程。部署模式较大的场景中，分发上线工作即繁杂又沉重。　　究其根本，所有的这些麻烦都是由于配置和代码在管理和发布过程中紧密耦合所致。配置本身源于代码，是为了提高代码的灵活性而提取出来的一些经常变化的或需要定制的内容，而正

2020-08-30 17:28:26 443

原创 Kubernetes学习之PV、PVC

一、认识PV、PVC　　PersistentVolume（PV）是指集群管理员配置提供的某存储系统上的一段存储空间，它是对底层共享存储的抽象，将共享存储作为一种可由用户申请使用的资源，实现了"存储消费"机制。通过存储插件，PV支持使用多种网络存储或云端存储等多种后端存储系统，例如，前面使用到的NFS、还有其他的如RBD、Cinder等。PV是集群级别的资源，不属于任何的名称空间，用户对PV资源的使用需要通过PersistentVolumeClaim（PVC）提出的使用申请（或称为声明）来完成绑定，PVC是

2020-08-29 18:06:08 1093

原创 Kubernetes学习之存储卷

一、存储卷概述　　应用程序在处理请求时，可根据其对当前请求的处理是否受影响与此前的请求，将应用划分为有状态和无状态应用两种。微服务体系中，各种应用均被拆分了众多微服务或更小的应用模块，因此往往会存在为数不少的有状态应用，于是数据持久化几乎是必然只需。　　Kubernetes提供的存储卷（volume）隶属于Pod资源，共享于Pod内的所有容器，可用于在容器的文件系统之外存储应用程序的相关数据，甚至还可以独立于Pod的生命周期之外实现数据持久化。　　Pod本身具有生命周期，故其内部运行的容器及其相关数据

2020-08-27 09:50:23 493

原创 Kubernetes学习之Ingress

一、认识Ingress　　Kubernetes提供了两种内建的负载均衡机制（cloud load balancing）用于发布公共应用，一种是工作于传输层的Service资源，它实现的是"TCP负载均衡器"，另一种是Ingress资源，它实现的是"HTTP(S)负载均衡器"。　　Kubernetes中，Service资源和Pod资源的IP地址仅能用于集群网络内部的通信，所有的网络流量都无法穿透边界路由器（Edge Router）以实现集群内外通信。尽管可以为Service使用NodePort或者Load

2020-08-26 10:04:17 699

原创 Kubernetes学习之Service

一、认识Service　　Service是Kubernetes的核心资源之一，通常可看做是微服务的一种实现。事实上它是一种抽象：通过规则定义出由多个Pod对象组合而成的逻辑集合，以及访问这组Pod的策略；Service关联Pod资源的规则要借助Selector标签选择器来完成。　　由Deployment等控制器管理的Pod对象中断后由新建的资源对象所取代，而扩缩容后的应用则会带来Pod对象群体的变动，随之变化的还有Pod的IP地址访问接口等等，这也是编排系统之上的应用程序必然要面临的问题，为了解决Kub

2020-08-20 20:58:08 476

原创 Kubernetes学习之Crontab控制器

一、认识Crontab控制器　　CronJob控制器用于管理Job控制器资源的运行时间。Job控制器定义的作业任务在其控制器资源创建之后便会立即执行，但是CronJob可以以类似于Linux操作系统中的周期任务作业计划（crontab）的方式控制其运行的时间点及重复运行的方式，具体如下：　　1）在未来某个时间点运行作业一次　　2）在指定的时间点重复运行作业　　CronJob对象支持使用时间格式类似于CronJob，略微有不同的是，CronJob控制器在指定的时间点时，"?“和”*"的意义相同，都表示

2020-08-10 09:37:07 841

原创 Kubernetes学习之Job控制器

一、认识Job控制器　　Job控制器用于调配Pod对象运行一次性任务，容器中的进程在正常运行结束后不会对其进行重启，而是将Pod对象置于"Completed"（完成状态），若是容器中进程因错误而终止了，则需要依配置确定是否重启，未运行完成的Pod对象因其所在的节点故障而意外终止后被重新调度。　　Job Controller负责根据Job Spec中的定义来创建Pod，并持续监控Pod状态，直至其成功结束。如果失败了，则根据用户定义的restartPolicy（只支持OnFailure和Never，不支持

2020-08-10 09:24:08 430

原创 Kubernetes学习之DaemonSet控制器

一、认识DaemonSet控制器　　DaemonSet是Pod控制器的又一种实现，用于在集群中的全部节点上同时运行一份指定的Pod资源副本，后续加入集群的工作节点也会自动创建一个相关的Pod对象，当从集群移除节点时，此类Pod对象也将被自动回收而无需重建。管理员也可以使用节点选择器及节点标签指定仅在部分具有特定特征的节点上运行指定的Pod对象。DaemonSet控制器是一种特殊的控制器，它有特定的应用场景，通常运行那些执行系统级操作任务的应用，其应用场景具体如下：　　1）运行集群存储的守护进程，如在

2020-08-01 17:57:38 564

原创 Kubernetes学习之Pod探测

一、Pod存活性探测　　有不少的应用长时间持续运行后逐渐转为不可用状态，并且仅能通过重启操作来恢复，Kubernetes的容器存活性探测机制可发现诸如此类的问题，并根据探测结果结合重启策略触发后续的行为。存活性探测是隶属于容器级别的配置，kubelet可基于它判定何时需要重启一个容器，该诊断操作由容器的处理器（handler）进行定义的。Kubernetes支持三种处理器用于Pod的探测：　　1）ExecAction：在容器中执行一个命令，并根据其返回的状态码进行诊断的操作称为Exec探测，状态码为0表

2020-07-31 20:44:39 549

原创 Kubernetes学习之初始化容器、钩子函数

一、初始化容器　　初始化容器（init container）即应用程序的主容器启动之前需要运行的容器，常用于为主容器执行一些预置的操作，它们具有两种典型特征：　　1）初始化容器必须运行完成直至结束，若某个初始化容器运行失败，那么Kubernetes需要重启此容器直到它成功启动　　2）每个初始化容器都必须按定义顺序的串行的来运行　　有不少的场景都需要在应用容器启动之前进行部分初始化操作，例如，等待其他关联组件服务可用、基于环境变量或配置模板为应用程序生成配置文件、从配置中心获取配置等；初始化容器的典

2020-07-31 17:36:53 416

原创 Kubernetes学习之Deployment控制器

一、认识Deployment控制器　　Deployment控制器为Pod和Replica Set控制器提供声明式的更新；你只需要在Deployment中描述你想要的目标状态是什么，Deployment Controller就会帮你将Pod和Relica Set控制器的实际状态改变到你的目标状态。你也可以定义一个新的Deployment，也可以创建一个新的替换旧的Deployment控制器。　　当我们在使用Deployment控制器做滚动更新时，Deployment控制器首先会创建出一个新的Replica

2020-07-26 14:47:41 407

原创 Kubernetes学习之Labels、Namespace

一、认识Labels　　Labels即为标签的意思，标签就是一对key/value键值对，被关联到对象之上，比如Pod，标签的使用可以方便的对K8S所创建的资源进行标记和记录对象资源的一些特殊特点；并且这些对用户而言是有意义的（比如可以对提供web服务的Pod和提供db存储的Pod进行标记与区分）。但是标签对内核系统是没有直接意义的。标签可以用来划分特定组的对象，标签可以在创建一个对象的时候直接给与，也可以在后期随时修改，每一个对象可以拥有多个标签，但是，key值必须是唯一的。　　　　K8S的Labe

2020-07-26 13:00:28 1017

原创 Kubernetes学习之Replication Set控制器

一、认识Pod　　Pod资源对象是一种集合了一到多个应用容器、存储资源、专用IP及支撑容器运行的其他选项的逻辑组件；Pod代表着Kubernetes的部署单元及原子运行单元，即一个应用程序的单一运行实例，它通常由共享资源且关系紧密的一个或多个容器组成；Kubernetes的网络模型要求其各Pod对象的IP地址位于同一网络平面内（同一个IP网段），各Pod之间可使用其IP地址直接进行通信，无论它们运行于哪个工作节点之上，这些Pod对象都像是运行于同一局域网中的多个主机。　　我们可以将每个Pod对象想象成一

2020-07-17 19:31:14 372

原创 Kubernetes学习之搭建Dashboard

Kubernetes Dashboard是k8s集群的一个WEB UI管理工具，代码托管在 github 上地址：https://github.com/kubernetes/dashboard1）部署dashboardkubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v2.0.0-rc5/aio/deploy/recommended.yamlkubectl get pods -n kubernetes-d

2020-07-16 20:45:02 247

原创 Kubernetes学习之搭建Kubernetes集群

一、环境介绍Master节点：172.16.2.100Node1节点：172.16.2.101Node2节点：172.16.2.102二、系统初始化以下所有系统初始化操作三个节点都需要执行1）同步时间yum install -y ntpdatentpdate ntp1.aliyun.com2）添加各节点的主机hosts记录cat >> /etc/hosts << EOF172.16.2.100 master172.16.2.101 node1

2020-07-04 17:17:33 342

空空如也

空空如也