CDC

Place to Be & Show Yourself

Centos7 安装 kubernetes

1. 介绍

1.1 docker介绍

docker 是kubertnetes的运行基础。在了解kubernetes前应当先了解docker.

1.1.1 介绍

软件开发会趋于复杂,带来的最大的麻烦在于环境配置。特别是不同的应用有不同的依赖,当软件升级时,依赖冲突经常变成难以解决的问题。

传统解决环境配置的方法是针对不同应用使用不同虚拟机部署,但是虚拟机耗费资源,而且性能损失不小,同时启动慢。

另外一种方式就是使用名字空间和资源分组对应用进行隔离,使应用运行在自己的虚拟环境中(但是不会进行整个系统的虚拟)。由于不需要进行操作系统级别的虚拟化,仅进行应用运行环境的隔离,优点是资源占用小,启动快,性能损失少。这个典型的解决方案是docker。

《Centos7 安装 kubernetes》

同时由于docker封装了应用和运行环境, 这个特点很适合把传统应用微服务化。微服务化可以使软件实现弹性扩展、快速迭代,促进DevOps(DevOps 强调的是高效组织团队之间如何通过自动化的工具协作和沟通来完成软件的生命周期管理,从而更快、更频繁地交付更稳定的软件。有工具支持,运维关注代码,开发关注部署,效率和质量都能得到提升。)

《Centos7 安装 kubernetes》

1.1.2 docker 依赖技术

Docker中的容器化是通过依赖两大技术:
* 资源隔离(cgroups),内核名称空间(隔离应用程序的操作系统视图,进程树等)
* 支持联合的文件系统(例如aufs – 将多个目录安装到一个看似于包含它们的组合内容)。

《Centos7 安装 kubernetes》

1.1.3 docker 概念

docker 有3个核心概念:
* 镜像(Image): 应用程序映像。
镜像是一个特殊的文件系统,除了提供容器运行时所需的程序、库、资源、配置等文件外,还包含了一些为运行时准备的一些配置参数(如匿名卷、环境变量、用户等)。镜像不包含任何动态数据,其内容在构建之后也不会被改变。

  • 容器(Container):正在运行的Image。但是运行的Image不会修改Image本身内容,所有对Image的改动在容器停止运行后丢失,为了避免数据丢失可以在运行时mount 本地目录。

  • 仓库(Docker registry): Docker 仓库是集中存放镜像文件的场所。镜像构建完成后,可以很容易的在当前宿主上运行。
    但是, 如果需要在其他服务器上使用这个镜像,我们就需要一个集中的存储、分发镜像的服务,Docker Registry(仓库注册服务器)就是这样的服务。

另外:
* Dockerfile: 声明了Image 怎样被创建的规则。

下面是他们的关系列表:

《Centos7 安装 kubernetes》

容器和映像的文件系统关系如下:
容器在映像上面增加了一个可写层,但是每一次容器退出,这个可写层的内容就丢失,所以容器每一次运行文件系统都是相同的:

《Centos7 安装 kubernetes》

1.1.4 第一个例子: 在CentOS上运行 Ubuntu

这个例子体现了docker作为轻量级虚拟机的特点(共用内核,但是系统不一样):

安装Docker:

用 docker pull ubuntu 把ubuntu下载到本地:

docker images 看到ubuntu到镜像仅 69MB 大小,这比起虚拟机来小太多了。而后面安装应用程序时仅添加应用程序的依赖,使得环境很简洁。

运行ubuntu:

另外启动一个终端,使用docker ps 可以看到容器已经运行, ifconfig 看到docker0网桥,和 veth 开始的表示给容器使用的网卡, docker inspect 查看容器信息:

docker run -it –rm -v /home/:/builddir ubuntu /bin/bash 意义:
* -i : interactive 交互模式, 可以输入命令
* -t : tty 分配一个控制台
* –rm: 当容器退出时清除容器文件系统
* -v /home/:/builddir : 把本地的/home目录映射到容器内的 /builddir 目录
* ubuntu: 镜像名称
* /bin/bash: 容器启动的命令。

在容器中可以象在真实系统中一样读写,但是仅在映射的目录下的改动才会保存。
按control-d 或是输入 exit 退出 /bin/bash, 同时发现容器也退出了,docker ps 看不到容器信息。
上面就体验到容器就是应用程序的执行环境,当应用程序退出后容器也就退出了。

1.1.5 第二个例子: 启动nginx 服务

上面的例子体验了容器访问本地目录功能
这个例子体验容器当成服务器运行功能, 体现了docker 作为服务器应用的分发工具特色(一个镜像就是应用的完整运行环境,即拉即用(pull and run))。

可见nginx 才109MB

下面是运行,这次是后台运行,所以原来的 -it 不用(交互和控制台),取代成 -d (守护模式)
同时加了 -p 8081:80 表示把本地的8081 tcp端口映射到 容器内的 80 端口
最后使用 curl 访问了一下,发现访问成功。

运行完后使用 docker kill 停止容器。

1.1.6 docker 命令介绍

《Centos7 安装 kubernetes》

1.1.7 构建自己的镜像

构建自己的镜像有多个方法,例如直接从 tar 包生成,
但是大部分镜像都是继承某个系统,例如在ubuntu或是centos (因为大部分应用都是在某个系统上开发)
这时就使用dockerfile, 下面是它的一个例子:
Dockerfile文件格式如下:

Dockerfile 分为四部分:基础镜像信息、维护者信息、镜像操作指令、容器启动执行指令。
* 一开始必须要指明所基于的镜像名称,
* 接下来一般会说明维护者信息;
* 后面则是镜像操作指令,例如 RUN 指令。每执行一条RUN 指令,镜像添加新的一层,并提交;
* 最后是 CMD 指令,来指明运行容器时的操作命令。

构建

构建好后 docker images 可以看到新建的镜像.

1.2. kubernetes介绍

Kubernetes(k8s)是Google开源的容器集群管理系统(谷歌内部:Borg), 在Docker技术的基础上,为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能,提高了大规模容器集群管理的便捷性。下面是他的主要功能:

《Centos7 安装 kubernetes》

kubernetes的两个设计理念依赖:

  1. docker。
    它让开发者将自己的应用以及依赖打包到一个可移植的容器中,让应用程序的运行可以实现环境无关。docker是微服务良好的载体。

  2. 微服务。
    随着软件变得越来越复杂,一个完整的后端服务不再是单体服务,而是由多个职责和功能不同的服务组成,服务之间复杂的拓扑关系以及单机已经无法满足的性能需求使得软件的部署和运维工作变得非常复杂,这也就使得部署和运维大型集群变成了非常迫切的需求。微服务应运而生。

Kubernetes优势:
*      – 容器编排
*      – 轻量级
*      – 开源
*      – 弹性伸缩
*      – 负载均衡

kubernetes架构,如下图,由一个master和多个worker(也叫Node/Slave)组成, Master负责管理集群,提供集群的资源数据访问入口, Worker(Node/Slave)用来承载被分配Pod的运行,是Pod运行的宿主机:

《Centos7 安装 kubernetes》

内部工作流程交互如下:

《Centos7 安装 kubernetes》

1.3. kubernetes关键概念

1.3.1. Master

k8s集群的管理节点,负责管理集群,提供集群的资源数据访问入口。
《Centos7 安装 kubernetes》

拥有Etcd存储服务(可选),运行Api Server进程,Controller Manager服务进程及Scheduler服务进程,关联工作节点Node。

Kubernetes API server提供HTTP Rest接口的关键服务进程,是Kubernetes里所有资源的增、删、改、查等操作的唯一入口。也是集群控制的入口进程;

Kubernetes Controller Manager是Kubernetes所有资源对象的自动化控制中心;

Kubernetes Schedule是负责资源调度(Pod调度)的进程。

1.3.2. Node(Worker)

《Centos7 安装 kubernetes》

Node是Kubernetes集群操作的单元,用来承载被分配Pod的运行,是Pod运行的宿主机。关联Master管理节点,拥有名称和IP、系统资源信息。

运行docker eninge服务,守护进程kunelet及负载均衡器kube-proxy.
每个Node节点都运行着以下一组关键进程
kubelet:负责对Pod对于的容器的创建、启停等任务
kube-proxy:实现Kubernetes Service的通信与负载均衡机制的重要组件
Docker Engine(Docker):Docker引擎,负责本机容器的创建和管理工作。

1.3.3. POD

在Kubernetes中最小的部署单位。

《Centos7 安装 kubernetes》

Pod由一至多个容器所组成,而在一般应用层面上由于下述几点原因,使其较接近于一般使用的VM:

  • 共享同样的IP位址及Port space
    同个Pod内的容器可以透过localhost来互相沟通

Pod可以直接透过该IP和其他Pod进行联系,但一般而言我们会透过service来取代直接Pod存取
* 共享储存空间(volumes)
* 耦合性较高之应用,例如:

《Centos7 安装 kubernetes》

为什么不直接在一个容器中运行多个应用程序呢?

  • 透明。让Pod中的容器对基础设施可见,以便基础设施能够为这些容器提供服务,例如进程管理和资源监控。这可以为用户带来极大的便利。
  • 解耦软件依赖。每个容器都可以进行版本管理,独立的编译和发布。未来kubernetes甚至可能支持单个容器的在线升级。
  • 使用方便。用户不必运行自己的进程管理器,还要担心错误信号传播等。
  • 效率。因为由基础架构提供更多的职责,所以容器可以变得更加轻量级。

1.3.4. Replication Controller/RS/Deployment

副本控制器(Replication Controller,RC)

用来管理Pod的副本,保证集群中存在指定数量的Pod副本。

集群中副本的数量大于指定数量,则会停止指定数量之外的多余容器数量,反之,则会启动少于指定数量个数的容器,保证数量不变。

Replication Controller是实现弹性伸缩、动态扩容和滚动升级的核心。

副本集(Replica Set,RS)

RS是新一代RC,提供同样的高可用能力,区别主要在于RS后来居上,能支持更多种类的匹配模式。副本集对象一般不单独使用,而是作为Deployment的理想状态参数使用。

部署(Deployment)

部署表示用户对Kubernetes集群的一次更新操作。部署是一个比RS应用模式更广的API对象,可以是创建一个新的服务,更新一个新的服务,也可以是滚动升级一个服务。滚动升级一个服务,实际是创建一个新的RS,然后逐渐将新RS中副本数增加到理想状态,将旧RS中的副本数减小到0的复合操作;这样一个复合操作用一个RS是不太好描述的,所以用一个更通用的Deployment来描述。以Kubernetes的发展方向,未来对所有长期伺服型的的业务的管理,都会通过Deployment来管理。

有状态服务集(StatefulSet)

  • RC和RS主要是控制提供无状态服务的,其所控制的Pod的名字是随机设置的,一个Pod出故障了就被丢弃掉,在另一个地方重启一个新的Pod,名字变了。名字和启动在哪儿都不重要,重要的只是Pod总数;
  • 而StatefulSet是用来控制有状态服务,StatefulSet中的每个Pod的名字都是事先确定的,不能更改。

  • 对于RC和RS中的Pod,一般不挂载存储或者挂载共享存储,保存的是所有Pod共享的状态,Pod像牲畜一样没有分别(这似乎也确实意味着失去了人性特征);

  • 对于StatefulSet中的Pod,每个Pod挂载自己独立的存储,如果一个Pod出现故障,从其他节点启动一个同样名字的Pod,要挂载上原来Pod的存储继续以它的状态提供服务。

1.3.5. service

Kubernetes Service是个抽象化的概念,主要定义了逻辑上的一群Pod(带着相同标签、做类似事情的一群Pod)以及如何存取他们的规则。

Service作为中介层,避免使用者和Pod进行直接联机,除了让我们服务维持一定弹性能够选择不同的Pod来处理请求外,某种程度上亦避免裸露无谓的Port而导致信息安全问题。

对于使用者而言,仅须知道有人会处理他们的请求,而毋须知道实际上处理的人是谁。

《Centos7 安装 kubernetes》

关于Service相关IP:

  • Pod IP:每个pod 都有独立的虚拟IP, 通过网络插件创建IP(如flannel),使跨主机的Pod可以互通

  • Cluster IP:是Service的内部IP,可以看成一个域名解析,解析最后发给哪个POD,可以用做内部POD访问服务。通过iptables规则访问服务。

  • External IP: 是Service的外部IP,对外提供给Client访问。

Pod IP 和 Cluster IP 都是kubernetes内部ip。

1.3.6. Label

Kubernetes中的任意API对象都是通过Label进行标识,Label的实质是一系列的Key/Value键值对,其中key于value由用户自己指定。

Label可以附加在各种资源对象上,如Node、Pod、Service、RC等,一个资源对象可以定义任意数量的Label,同一个Label也可以被添加到任意数量的资源对象上去。

Label是Replication Controller和Service运行的基础,二者通过Label来进行关联Node上运行的Pod。

1.3.7. 存储卷(Volume)

Kubernetes集群中的存储卷跟Docker的存储卷有些类似,只不过Docker的存储卷作用范围为一个容器,而Kubernetes的存储卷的生命周期和作用范围是一个Pod。每个Pod中声明的存储卷由Pod中的所有容器共享。

Kubernetes支持非常多的存储卷类型,特别的,支持多种公有云平台的存储,包括AWS,Google和Azure云;
支持多种分布式存储包括GlusterFS和Ceph;也支持较容易使用的主机本地目录emptyDir, hostPath和NFS。
Kubernetes还支持使用Persistent Volume Claim即PVC这种逻辑存储,使用这种存储,使得存储的使用者可以忽略后台的实际存储技术(例如AWS,Google或GlusterFS和Ceph),而将有关存储实际技术的配置交给存储管理员通过Persistent Volume来配置。

持久存储卷(Persistent Volume,PV)和持久存储卷声明(Persistent Volume Claim,PVC
PV和PVC使得Kubernetes集群具备了存储的逻辑抽象能力,使得在配置Pod的逻辑里可以忽略对实际后台存储技术的配置,而把这项配置的工作交给PV的配置者,即集群的管理者。
存储的PV和PVC的这种关系,跟计算的Node和Pod的关系是非常类似的;
PV和Node是资源的提供者,根据集群的基础设施变化而变化,由Kubernetes集群管理员配置;
而PVC和Pod是资源的使用者,根据业务服务的需求变化而变化,有Kubernetes集群的使用者即服务的管理员来配置。

1.4. 使用yaml描述对象

1.4.1 YAML语法

kubernetes使用YAML写对象信息, YAML语法规则:

  • 大小写敏感
  • 使用缩进表示层级关系
  • 缩进时不允许使用Tal键,只允许使用空格
  • 缩进的空格数目不重要,只要相同层级的元素左侧对齐即可
  • ”#” 表示注释,从这个字符一直到行尾,都会被解析器忽略

1.4.2 Pod, Service和Deployment

Kubernetes有三个你应该知道的对象类型:

  • Pods – 运行一个或多个密切相关的容器
  • Service – 在Kubernetes集群中建立网络
  • Deployment – 维护一组相同的pod,确保它们具有正确的配置并且存在正确的数量。

Pod:

  • 运行一组容器
  • 适合一次性开发目的
  • 很少直接用于生产

Deployment:

  • 运行一组相同的pod
  • 监视每个pod的状态,并根据需要进行更新
  • 对开发者有好处
  • 适合生产

尽量避免使用Pod并实施Deployments来管理容器作为类型的对象
Pod在节点故障或pod终止时不会被重新安排(或自我修复)。

1.4.3. 使用yaml描述对象

在 Kubernetes 系统中,Kubernetes 对象 是持久化的实体。Kubernetes 使用这些实体去表示整个集群的状态。特别地,它们描述了如下信息:

  • 哪些容器化应用在运行(以及在哪个 Node 上)
  • 可以被应用使用的资源
  • 关于应用运行时表现的策略,比如重启策略、升级策略,以及容错策略

可以简单的分类为以下几种资源对象:

类别 名称
资源对象 Pod、ReplicaSet、ReplicationController、Deployment、StatefulSet、DaemonSet、 Job、CronJob、 HorizontalPodAutoscaling、Node、Namespace、Service、 Ingress、Label、CustomResourceDefinition
存储对象 Volume、PersistentVolume、Secret、ConfigMap
策略对象 SecurityContext、ResourceQuota、LimitRange
身份对象 ServiceAccount、Role、ClusterRole

大多数情况下,需要在 .yaml 文件中为 kubectl 提供对象信息。

在想要创建的 Kubernetes 对象对应的 .yaml 文件中,需要配置如下的字段:

  • apiVersion – 创建该对象所使用的 Kubernetes API 的版本
  • kind – 想要创建的对象的类型
  • metadata – 帮助识别对象唯一性的数据,包括一个 name 字符串、UID 和可选的 namespace

这里有更多例子:

Kubernetes Yaml Templates

下面是一些常用例子:

  • Endpoints

可以把外部的链接到k8s系统中,如下将一个mysql连接到k8s中。

  • service

1.4.2. pod配置例子

1.4.3. deployment

部署一个Pod,内部只能链接service,无法互相链接.

1.4.4. Service

部署一个内部虚拟IP,其他deployment可以链接。

1.4.5. ingress

你可以给Ingress配置提供外部可访问的URL、负载均衡、SSL、基于名称的虚拟主机等。用户通过POST Ingress资源到API server的方式来请求ingress。 Ingress controller负责实现Ingress,通常使用负载平衡器,它还可以配置边界路由和其他前端,这有助于以HA方式处理流量。

1.5. kubernetes其他功能介绍

configmaps: 为了让应用程序可以方便转移或避免重新编译image,因此会将配置与应用程序解构,以单独的ConfigMap配置.

永久性存储Persistent Volume: Pod 里面指定mountPath和 type.

1.6. kubernetes第三方工具

Jaeger是一个开源的分布式跟踪Trace系统,可以用来trace每个客户端送出的请求,进而找出执行过程的问题.

Helm是一个可以安装与管理Kubernetes应用程序的工具,我们可以将Helm视为是Kubernetes的package manager.

普罗米修斯(Prometheus)是一个可以提供Kubernetes应用程序测量的开源套件,一方面可以汇整测量信息,也可以提供警告(Alert)通知.

Deployment通常是首选,因为它定义了ReplicaSet以确保所需数量的Pod始终可用,并指定替换Pod的策略,例如RollingUpdate。

1.7. kubernetes网络

Kubernetes本身并不提供网络功能,只是把网络接口开放出来,通过插件的形式实现。
Kubernetes中的网络要解决的核心问题就是每台主机的IP地址网段划分,以及单个容器的IP地址分配。概括为:

  • 保证每个Pod拥有一个集群内唯一的IP地址
  • 保证不同节点的IP地址划分不会重复
  • 保证跨节点的Pod可以互相通信
  • 保证不同节点的Pod可以与跨节点的主机互相通信

为了解决该问题,出现了一系列开源的Kubernetes中的网络插件与方案,如:

  • flannel
  • calico
  • contiv
  • weave net
  • kube-router
  • cilium
  • canal

《Centos7 安装 kubernetes》

1.7.1. flannel网络

Flannel是作为一个二进制文件的方式部署在每个node上,主要实现两个功能:

  • 为每个node分配subnet,容器将自动从该子网中获取IP地址
  • 当有node加入到网络中时,为每个node增加路由配置

下面是flannel网络的运行模式:

《Centos7 安装 kubernetes》

Flannel首先创建了一个名为flannel0的网桥,而且这个网桥的一端连接docker0的网桥,另一端连接一个名为flanneld的服务进程。

Flanneld进程并不简单,它首先上连etcd,利用etcd来管理可分配的IP地址段资源,同时监控etcd中每个Pod的实际地址,并在内存中建立了一个Pod节点路由表;然后下连docker0和物理网络,使用内存中的Pod节点路由表,将docker0发给它的数据包包装起来,利用物理网络的连接将数据包投递到目标flanneld上,从而完成pod到pod之间的直接的地址通信。

Flannel之间的底层通信协议的可选余地有很多,比如UDP、VXlan、AWS VPC等等。只要能通到对端的Flannel就可以了。源Flannel封包,目标Flannel解包,最终docker0看到的就是原始的数据,非常透明,根本感觉不到中间Flannel的存在。

  • 数据从源容器中发出后,经由所在主机的docker0虚拟网卡转发到flannel0虚拟网卡,这是个P2P的虚拟网卡,flanneld服务监听在网卡的另外一端。
  • Flannel通过Etcd服务维护了一张节点间的路由表。
  • 源主机的flanneld服务将原本的数据内容UDP封装后根据自己的路由表投递给目的节点的flanneld服务,数据到达以后被解包,然后直接进入目的节点的flannel0虚拟网卡,
    然后被转发到目的主机的docker0虚拟网卡,最后就像本机容器通信一下的有docker0路由到达目标容器。

总结:
* 1. 基于 UDP 的 flannel 网络模型具有简单易用,不依赖底层网络的特点
* 2. 性能和时延问题。
Flannel实现了对Kubernetes网络的支持,但是它引入了多个网络组件,在网络通信时需要转到flannel0网络接口,再转到用户态的flanneld程序,到对端后还需要走这个过程的反过程,所以也会引入一些网络的时延损耗。另外Flannel默认的底层通信协议是UDP。UDP本身是非可靠协议,虽然两端的TCP实现了可靠传输,但在大流量、高并发应用场景下还需要反复调试,确保不会出现传输质量的问题。特别是对网络依赖重的应用,需要评估对业务的影响。

1.7.2. Calico

Calico创建和管理一个扁平的三层网络(不需要overlay),每个容器会分配一个可路由的IP。由于通信时不需要解包和封包,网络性能损耗小,易于排查,且易于水平扩展。

小规模部署时可以通过BGP client直接互联,大规模下可通过指定的BGP Route Reflector来完成,这样保证所有的数据流量都是通过IP路由的方式完成互联的。

Calico基于iptables还提供了丰富而灵活的网络Policy,保证通过各个节点上的ACL来提供Workload的多租户隔离、安全组以及其他可达性限制等功能。
《Centos7 安装 kubernetes》

Calico主要由Felix、etcd、BGP client、BGP Route Reflector组成。

  • Etcd:负责存储网络信息
  • BGP client:负责将Felix配置的路由信息分发到其他节点
  • Felix:Calico Agent,每个节点都需要运行,主要负责配置路由、配置ACLs、报告状态
  • BGP Route Reflector:大规模部署时需要用到,作为BGP client的中心连接点,可以避免每个节点互联

1.8. 云上的kubernetes

在 Kubernetes 出现之前,就已经有人提出了云原生的概念,如 2010 年 Paul Fremantle 就在他的博客中提出了云原生的核心理念,但是还没有切实的技术解决方案。

而那时候 PaaS 才刚刚出现,PaaS 平台提供商 Heroku 提出了 12 因素应用的理念,为构建 SaaS 应用提供了方法论,该理念在云原生时代依然适用。

现如今云已经可以为我们提供稳定而唾手可得的基础设施,但是业务上云成了一个难题,Kubernetes 的出现与其说是从最初的容器编排解决方案开始,倒不如说是为了解决应用上云(即云原生应用)这个难题。

Kubernetes 作为云应用的部署标准,直接面向业务应用,大大提高了云应用的可移植性,解决云厂商锁定的问题,让云应用可以在夸云之间无缝迁移,甚至用来管理混合云,成为企业 IT 云平台的新标准。

1.8.1 AKS 介绍

微软的Azure Kubernetes Service以下简称AKS,提供简单的部署,管理与操作界面,具有以下的几个特点:

  • 订阅者不必担心升级与修正问题,AKS提供自动更新与修正
  • AKS服务具有高可用度与高可靠性
  • AKS可以透过命令或UI简单的调整扩充
  • AKS具有自我修复能力
  • AKS提供API Server监控机制
  • AKS可以透过Azure AD以及Role Base Access Control(RBAC)控管丛集的存取安全性
  • AKS服务的Azure托管的管理控制平台(Control plane/Master nodes)提供免费使用
    这边要特别说明,AKS管理控制平台是由微软托管的,订阅者不需要设定Master nodes,订阅的使用者透过Kubernetes API endpoint,使用命令(Azure Cli – az aks)来管理AKS.
    《Centos7 安装 kubernetes》

2. Centos7安装

安装可以分成3个部分:

配置系统参数,例如使用不同的hostname , 禁止swap和 selinux,允许防火墙通过某些端口等等
在所有节点上安装docker
在所有节点上安装kubernetes
配置主节点
在worker节点上向主节点注册自己。
下面将分别介绍。

2.1. 配置系统参数

2.1.1. 每个机器使用不同的主机名

在每台机器上运行:

hostnamectl set-hostname new-hostname
如果没有自己的 DNS 服务器,那么需要修改所有机器的 /etc/hosts 文件,把kuberntes内所有主机名(master 和 worker node )和ip的对应添加进来, 例如:

2.1.2. 关闭selinux

2.1.3. 关闭swap

2.1.4. 配置网络防火墙

简单一些的办法是直接禁止:

复杂点是开放 kubernetes 需要的端口,下面是master node:

worker node:

2.1.5. 配置网络参数

2.2. 安装docker
kuberntes 使用docker作为pod 的运行基础。 CentOS7.6 自带的 docker 是支持kubernetes的。通过下面命令安装。

如果需要也可以使用最新的 docker-ce:

cat < /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg
https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
EOF
yum install -y kubelet kubeadm kubectl
systemctl enable kubelet && systemctl start kubelet

# https://blog.csdn.net/jb19900111/article/details/88884848
[[email protected] ~]# cat getk8s_images.sh
#!/bin/bash
images=(
kube-apiserver:v1.14.0
kube-controller-manager:v1.14.0
kube-scheduler:v1.14.0
kube-proxy:v1.14.0
pause:3.1
etcd:3.3.10
coredns:1.3.1
kubernetes-dashboard-amd64:v1.10.0
heapster-amd64:v1.5.4
heapster-grafana-amd64:v5.0.4
heapster-influxdb-amd64:v1.5.2
pause-amd64:3.1
)

for imageName in ${images[@]} ; do
docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/$imageName
docker tag registry.cn-hangzhou.aliyuncs.com/google_containers/$imageName k8s.gcr.io/$imageName
done
[[email protected] ~]# sh -x getk8s_images.sh

[[email protected] ~]# cat /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=http://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=0
repo_gpgcheck=0
gpgkey=http://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg
http://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg

[[email protected] ~]# yum -y install kubelet kubeadm kubectl –disableexcludes=kubernetes

docker info | grep -i cgroup

kubeadm init –apiserver-advertise-address=192.168.1.30 –pod-network-cidr=10.244.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

kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/a70459be0084506e4ec919aa1c114638878db11b/Documentation/kube-flannel.yml

sudo kubeadm join 192.168.0.120:6443 –token khm95w.mo0wwenu2o9hglls \
–discovery-token-ca-cert-hash sha256:aeb0ca593b63c8d674719858fd2397825825cebc552e3c165f00edb9671d6e32

#kubectl apply -f https://raw.githubusercontent.com/kubernetes/dashboard/v1.10.1/src/deploy/recommended/kubernetes-dashboard.yaml
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

sudo kubeadm join 192.168.0.120:6443 –token khm95w.mo0wwenu2o9hglls \
–discovery-token-ca-cert-hash sha256:aeb0ca593b63c8d674719858fd2397825825cebc552e3c165f00edb9671d6e32

kubectl get nodes
kubectl get pods –all-namespaces

[[email protected] ~]# kubectl create deployment nginx –image=nginx
deployment.apps/nginx created
[[email protected] ~]# kubectl describe deployment nginx
Name: nginx
Namespace: default
CreationTimestamp: Fri, 07 Jun 2019 23:24:06 -0400
Labels: app=nginx
Annotations: deployment.kubernetes.io/revision: 1
Selector: app=nginx
Replicas: 1 desired | 1 updated | 1 total | 0 available | 1 unavailable
StrategyType: RollingUpdate
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
Labels: app=nginx
Containers:
nginx:
Image: nginx
Port:
Host Port:
Environment:
Mounts:
Volumes:
Conditions:
Type Status Reason
—- —— ——
Available False MinimumReplicasUnavailable
Progressing True ReplicaSetUpdated
OldReplicaSets:
NewReplicaSet: nginx-65f88748fd (1/1 replicas created)
Events:
Type Reason Age From Message
—- —— —- —- ——-
Normal ScalingReplicaSet 10s deployment-controller Scaled up replica set nginx-65f88748fd to 1
[[email protected] ~]# kubectl create service nodeport nginx –tcp=80:80
service/nginx created
[[email protected] ~]# kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-65f88748fd-kjjdk 1/1 Running 0 44s
[[email protected] ~]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 443/TCP 39h
nginx NodePort 10.109.182.154 80:32303/TCP 13s

[[email protected] ~]# kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 443/TCP 39h
nginx NodePort 10.109.182.154 80:32303/TCP 13s
[[email protected] ~]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8smaster Ready master 39h v1.14.2
k8snode1 Ready 39h v1.14.2
[[email protected] ~]# curl k8snode1:32303

<title>Welcome to nginx!</title>

body {
width: 35em;
margin: 0 auto;
font-family: Tahoma, Verdana, Arial, sans-serif;
}

<h1>Welcome to nginx!</h1>
<p>If you see this page, the nginx web server is successfully installed and
working. Further configuration is required.</p>

<p>For online documentation and support please refer to
<a href=”http://nginx.org/”>nginx.org</a>.<br />
Commercial support is available at
<a href=”http://nginx.com/”>nginx.com</a>.</p>

<p><em>Thank you for using nginx.</em></p>

还可以访问 master node/ 或是 svr 运行的 worker node 的 svr 开放端口:

点赞

发表评论

电子邮件地址不会被公开。