荐 对Docker和k8s还只是了解，技术不进步那你怎么进大厂？

什么是Docker？

Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的镜像中，然后发布到任何流行的 Linux或Windows 机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口。

什么是Kubernetes？

Kubernetes是Google基于Borg开源的容器编排调度引擎,作为CNCF ( Cloud NativeComput ing Foundation )最重要的组件之一，它的目标不仅仅是-一个编排系统，而是提供一个规范，可以让你来描述集群的架构，定义服务的最终状态，Kubernetes可以帮你将系统自动地达到和维持在这个状态。Kubernetes 作为 云原生应用的基石，相当于一个云操作系统，其重要性不言而喻。

你的docker和Kubernetes还停留在初级？那还不赶紧往下看。相信看完这篇文章以后，你将会对Docker和Kubernetes有一个更加深入的认识，

使用kubeadm搭建集群环境

架构

上节课给大家讲解了k8s的基本概念与几个主要的组件，我们在了解了k8s 的基本概念过后,实际.上就可以去正式使用了,但是我们前面的课程都是在katacoda . 上面进行的演示，只提供给我们15分钟左右的使用时间，所以最好的方式还是我们自己来手动搭建-套k8s 的环境，在搭建环境之前，我们再来看一张更丰富的k8s的架构图。

 

●核心层: Kubernetes 最核心的功能，对外提供API构建高层的应用，对内提供插件式应用执行环境

●应用层:部署(无状态应用、有状态应用、批处理任务、集群应用等)和路由(服务发现、DNS解析等)

●管理层:系统度量(如基础设施、容器和网络的度量)，自动化(如自动扩展、动态Provision等)以及策略管理( RBAC. Quota. PSP、NetworkPolicy等)

●接口层: kubectl 命令行工具、客户端SDK以及集群联邦

●生态系统:在接口层之上的庞大容器集群管理调度的生态系统，可以划分为两个范畴

。Kubernetes 外部:日志、监控、配置管理、CI. CD、Workflow等

。Kubernetes 内部: CRI、 CNI、 CVI、 镜像仓库、Cloud Provider. 集群自身的配置和管理等

在更进一步了解了k8s集群的架构后，我们就可以来正确的的安装我们的k8s集群环境了，我们这

里使用的是kubeadm 工具来进行集群的搭建。

kubeadm是Kubernetes | 官方提供的用于快速安装Kubernetes 集群的工具,通过将集群的各个组件进行容器化安装管理，通过kubeadm 地方式安装集群比二进制的方式安装要方便不少，但是目前kubeadm还处于beta状态，还不能用于生产环境，Using kubeadm to Create aCluster文档中已经说明kubeadm 将会很快能够用于生产环境了。对于现阶段想要用于生产环境的，建议还是参考我们前面的文章:手动搭建高可用的kubernetes 集群或者视频教程。

 

深入理解Pod

YAML文件

18. YAML 文件

在前面的课程中，我们在安装kubernetes 集群的时候使用了一些YAML文件来创建相关的资源,但是很多同学对YAML文件还是非常陌生。所以我们先来简单看看YAML 文件是如何工作的，并使用YAML文件来定义一个kubernetes pod,然后再来定义一个kubernetes deployment吧。

YAML基础

它的基本语法规则如下:

●大小写敏感

●使用缩进表示层级关系

●缩进时不允许使用Tab键，只允许使用空格。

●缩进的空格数目不重要，只要相同层级的元素左侧对齐即可

●# | 表示注释,从这个字符一 直到行尾，都会被解析器忽略。

在我们的kubernetes 中,你只需要两种结构类型就行了:

●Lists

●Maps

也就是说，你可能会遇到Lists的Maps和Maps的Lists, 等等。不过不用担心，你只要掌握了这两种结构也就可以了，其他更加复杂的我们暂不讨论。

Maps

首先我们来看看Maps, 我们都知道Map 是字典，就是一个key:value的键值对， Maps可以让我们更加方便的去书写配置信息，例如:

---
apiversion: V1
kind: Pod

第一行的---是分隔符， 是可选的，菜单- -文件中，可用连续三个连字号---区分多个文件。这

里我们可以看到，我们有两个键:kind和apiversion | ,他们对应的值分别是: v1和Pod。上面的YAML文件转换成JSON 格式的话，你肯定就容易明白了:

 

Replication Controller与Replica Set

使用Replication Controller、 Replica Set管理Pod

前面我们的课程中学习了Pod 的一些基本使用方法，而且前面我们都是直接来操作的Pod ， 假如我们现在有一个Pod 正在提供线.上的服务，我们来想想一下我们可能会遇到的一些场景:

●某次运营活动非常成功，网站访问量突然暴增

●运行当前Pod的节点发生故障了，Pod 不能正常提供服务了

第一种情况，可能比较好应对，一般活动之前我们会大概计算下会有多大的访问量，提前多启动几个| Pod。活动结束后再把多余的Pod 杀掉，虽然有点麻烦，但是应该还是能够应对这种情况的。

第二种情况，可能某天夜里收到大量报警说服务挂了,然后起来打开电脑在另外的节点上重新启动一个新的Pod ，问题也很好的解决了。

如果我们都人工的去解决遇到的这些问题，似乎又回到了以前刀耕火种的时代了是吧，如果有一种工具能够来帮助我们管理Pod 就好了，Pod 不够了自动帮我新增一一个，Pod 为了自动帮我在合适的节点上重新启动一个Pod ，这样是不是遇到上面的问题我们都不需要手动去解决了。幸运的是,Kubernetes就为我们提供了这样的资源对象:

• Replication Controller: 用来部署、升级Pod
• Replica Set: 下一代的Replication Controller
• Deployment: 可以更加方便的管理Pod和Replica Set

Replication Controller ( RC )

Replication Controller简称RC

RC是| Kubernetes系统中的核心概念之一， 简单来说，RC 可以保证在任意时间运行 Pod 的副本数量， 能够保证Pod 总是可用的。 如果实际Pod数量比指定的多那就结束掉多余的，如果实际数量比指定的少就新启动一些Pod当Pod失败、被删除或者挂掉后,RC都会 去自动创建新的Pod 来保证副本数量， 所以即使只有一个Pod，我们也应该使用RC 来管理我们的Pod.

我们想想如果现在我们遇到上面的问题的话，可能除了第- - 能不能做到完全自动化，其余的我们是不是都不用担心了，运行Pod 的节点挂了，RC 检测到Pod 失败了， 就会去合适的节点重新启动一下| Pod 就行，不需要我们手动去新建一个Pod 了。如果是第一 种情况的话在活动开始之前我们给Pod指定10个副本，解冻后将副本数量改成2，这样是不是也远比我们手动去启动、手动去关闭要好得多，而且我们后面还会给大家介绍另外-种资源对象HPA 可以根据 资源的使用情况来进行自动扩所以，这样以后遇到这种情况，我们就真的可以安心的去睡觉了。

 

PV

PV的使用

前面我们和大家一起学习了一些基本的资 源对象的使用方法,前面我们也和大家讲到了有状态的应用和

对数据有持久化的应用，我们有通过hostPath 或者emp tyDir的方式来持久化我们的数据，但是

显然我们还需要更加可靠的存储来保存应用的持久化数据，这样容器在重建后，依然可以使用之前的数

据。但是显然存储资源和CPU资源以及内存资源有很大不同，为了屏蔽底层的技术实现细节，让用户

更加方便的使用，Kubernetes 便引入了PV和PVC两个重要的资源对象来实现对存储的管理。这

也是我们这节课需要和大家讲解的核心: PV和PVC。

概念

PV的全称是: Per sistentVolume (持久化卷)，是对底层的共享存储的一种抽象，PV由管理员进行创建和配置，它和具体的底层的共享存储技术的实现方式有关，比如Ceph、 GlusterFS. NFS等，都是通过插件机制完成与共享存储的对接。

PVC的全称是: PersistentVo lumeClaim (持久化卷声明)，PVC是用户存储的一种声明，PVC和Pod比较类似，Pod消耗的是节点，PVC消耗的是PV资源，Pod可以请求CPU 和内存，而PVC可以请求特定的存储空间和访问模式。对于真正使用存储的用户不需要关心底层的存储实现细节,只需要直接使用PVC即可。

但是通过PVC请求到一定的存储空间也很有可能不足以满足应用对于存储设备的各种需求，而且不同的应用程序对于存储性能的要求可能也不尽相同，比如读写速度、并发性能等，为了解决这一问题，Kubernetes又为我们引入了一个新的资源对象: StorageClass, 通过StorageClass 的定义, 管理员可以将存储资源定义为某种类型的资源，比如快速存储、慢速存储等，用户根据StorageClass的描述就可以非常直观的知道各种存储资源的具体特性了，这样就可以根据应用的特性去申请合适的存储资源了。

 

 

动态Jenkins Slave

基于Jenkins的CI/CD (一)

前面的课程中我们学习了持久化数据存储在| Kubernetes中的使用方法， 其实接下来按照我们的课程进度来说应该是讲解服务发现这一部分的内容的， 但是最近有很多同学要求我先讲解下CI/CD这块的内容，所以我们先把这块内容提前来讲解了。提到基于Kubernete 的CI/CD ， 可以使用的工具有很多，比如JenkinsGitlab CI已经新兴的drone 之类的， 我们这里会使用大家最为熟悉的Jenins来做CI/CD 的工具。

安装

听我们课程的大部分同学应该都或多或少的听说过Jenkins ， 我们这里就不再去详细讲述什么是Jenkins了,直接进入正题，后面我们会单独的关于Jenkins的学习课程，想更加深入学习的同学也可以关注下。既然要基于Kubernetes| 来做CI/CD ， 当然我们这里需要将Jenkins安装到Kubernetes集群当中，新建一个Deployment: (jenkins2 . yaml)

apiversion: extensions/v1beta1
kind: Deployment
me tadata:
name: jenkins2
namespace: kube-ops
spec:
template:
metadata:
labels:
app: jenkins2
spec:
terminationGracePer 1odSeconds: 10
containers:
name: jenkins
image: jenkins/jenkins:lts
imagePullPolicy: IfNotPresent
ports:
containerPort: 8080
name: web
protocol: TCP
containerPort: 50000

 

kubedns

内部服务发现

前面我们给大家讲解了Service 的用法，我们可以通过Service生成的ClusterIP(VIP)来访问Pod提供的服务，但是在使用的时候还有一个问题:我们怎么知道某个应用的VIP呢?比如我们.有两个应用，一个是api应用，一个是db应用，两个应用都是通过Deployment 进行管理的,并且都通过Service暴露出了端口提供服务。api需要连接到db这个应用，我们只知道db应用的名称和db对应的Service 的名称，但是并不知道它的VIP 地址，我们前面的Service 课程中是不是学习到我们通过ClusterIP就可以访问到后面的Pod服务，如果我们知道了VIP的地址是不是就行了?

apiserver

我们知道可以从apiserver 中直接查询获取到对应service的后端Endpoints信 息，所以最简单的办法是从apiserver 中直接查询，如果偶尔一个特殊的应用，我们通过apiserver 去查询到Service后面的Endpoints直接使用是没问题的，但是如果每个应用都在启动的时候去查询依赖的服务，这不但增加了应用的复杂度,这也导致了我们的应用需要依赖Kubernetes 了， 耦合度太高了，不具有通用性。

环境变量

为了解决上面的问题，在之前的版本中，Kubernetes 采用了环境变量的方法，每个Pod启动的时候，会通过环境变量设置所有服务的IP和port 信息，这样Pod中的应用可以通过读取环境变量来获取依赖服务的地址信息，这种方法使用起来相对简单，但是有一个很大的问题就是依赖的服务必须在Pod 启动之前就存在，不然是不会被注入到环境变量中的。比如我们首先创建一个Nginx 服务:(test -nginx . yaml)

apiversion: apps/v1beta1
kind: Deployment
metadata:
name: nginx - deploy
labels:
k8s - app: nginx- demo
spec :
replicas: 2
template:
metadata:

 

目录

 

因为内容太过详细，并不能全部展现，但是文档已经给大家准备好

分享，让知识传承更久远!感谢知识的创造者 ,感谢知识的分享者，也感谢每一位阅读到此处的读者，因为我们都将成为知识的传承者。

本文地址：https://blog.csdn.net/mrchaochao/article/details/107362921