实验报告
目录
一、 课堂练习
实践 — Kubernetes 微服务应用
1.创建mysql服务
2.创建web服务
实践 — Configmap练习
1、创建configmap
1、livenessProbe与readinessProbe
二、 课后作业
1. 完成课堂实践要求的练习，包括service的操作，要求截图
5. 描述configmap的功能，在容器中有几种使用方式
1.环境变量方式
3.设置容器命令行参数
7. Pod内对容器的健康检查有哪两种，各自的作用是什么？
httpGet
一、 课堂练习
实践 — Kubernetes 微服务应用
代码：
一个完整的网站应用
1.创建mysql服务
$ kubectl create -f hpe-mysql-svc.yaml
$ kubectl create -f hpe-mysql-rc.yaml
2.创建web服务
$ kubectl create -f hpe-myweb-svc.yaml
$ kubectl create -f hpe-myweb-rc.yaml
env:
- name: MYSQL_SERVICE_HOST
value: ‘hpe-mysql’ -> 使用服务名（DNS模式）
运行截图：
1、创建musql服务
2、同理创建web服务，这里可以看到web的也已经创建好了
3、访问localhost:30001/demo/
实践 — Configmap练习
内容：
1) 使用kubectl create configmap命令创建configmap
2) 将server.xml创建为configmap，并给hpe-myweb Pod使用
3) 将configmap cm-appvars中的数据设置为Pod容器内的环境变量
4) 将configmap cm-appconfigfiles中的文件设置为hpe-myweb Pod中的配置文件
5) 练习k8s_docker_build/build-hpe-myweb-configmap自定义基于configmap挂载文件的镜像，熟悉构建过程和启动脚本的作用。
运行截图：
1、创建configmap
2、将server.xml创建为configmap，并配置使用
3、将configmap cm-appvars中的数据设置为Pod容器内的环境变量
4、将configmap cm-appconfigfiles中的文件设置为hpe-myweb Pod中的配置文件
实践 — 健康检查和资源限制练习
内容：
1) 给hpe-myweb应用配置livenessprobe和readinessprobe
2) hpe-myweb RC的滚动升级，保证服务持续可用
1) 给hpe-myweb和hpe-mysql服务设置cpu和内存的资源限制
2) 新namespace a和b，给namespace a和b设置limitrange和resourcequota
运行截图：
1、livenessProbe与readinessProbe
2、设置限制
3、创建namespace b
4、limitrange，我们对namespace b进行apply即可。同时，由于resourcequota是默认开启的，在这里就不去管它了。
二、 课后作业
题目：
1. 完成课堂实践要求的练习，包括service的操作，要求截图
解答：
见上面课堂作业部分
题目：
2. 描述Service的主要作用，Service在k8s集群内的FQDN是怎样的格式，举例说明
解答：
Service是Kubernetes最核心的概念，通过创建Service,可以为一组具有相同功能的POD应用提供统一的访问入口，并且将请求进行负载分发到后端的各个容器应用上。在Kubernetes中，在受到RC调控的时候，Pod副本是变化的，对于的虚拟IP也是变化的，比如发生迁移或者伸缩的时候。这对于Pod的访问者来说是不可接受的。Kubernetes中的Service是一种抽象概念，它定义了一个Pod逻辑集合以及访问它们的策略，Service同Pod的关联同样是居于Label来完成的。Service的目标是提供一种桥梁，它会为访问者提供一个固定访问地址，用于在访问时重定向到相应的后端，这使得非Kubernetes原生应用程序，在无须为Kubemces编写特定代码得前提下，轻松访问后端。
Service同RC一样，都是通过Label来关联Pod的，当你在Service的yaml文件中定义了该service的selector中的label为app:my-web，那么这个service会将Pod-->metadata-->labels中label为app:my-web的Pod作为分发请求的后端。当Pod数量发生变化时，service会及时更新。这样一来，service就可以作为Pod的访问入口，起到代理服务器的作用，而对于访问者来说，通过service进行访问，无需直接感知Pod。
service中的FQDN:
ExternalName: 是用于将集群外部的服务引入到集群内部，在集群内部可直接访问来获取值，该值是FQDN, 这个FQDN为集群内部的FQDN, 即:ServiceName.Namespace.Domain.LTD.然后CoreDNS接受到该FQDN后，能解析出一个CNAME记录, 该别名记录为真正互联网上的域名。如: www.test.com,接着CoreDNS在向互联网上的根域DNS解析该域名，获得其真实互联网IP。
题目：
3. Service对集群外客户端提供访问有几种方式，应如何设置？
解答：
Ø 将容器应用的端口号映射到物理机
1. 通过设置容器级别的hostPort，将容器应用的端口号映射到物理机上。
2. 通过设置Pod级别的hostNetwork=true，改Pod中所有容器的端口号都将被直接映射到物理机上。设置hostNetwork=true时需要注意，在容器的ports定义部分如果不指定hostPort，则默认hostPort等于containerPort，如果制定了hostPort，则hostPort必须等于containerPort的值。
Ø 将Service的端口号映射到物理机
3. 通过设置nodePort映射到物理机，同时设置Service的类型为NodePort
4. 通过设置LoadBalancer映射到云服务商提供的LoadBalancer地址。这种方法仅用于在公有云服务提供商的云平台上设置Service的场景。
题目：
4. 网上查询资料，描述k8s集群内为服务名提供DNS域名解析的基础服务是由什么软件提供的，其主要工作原理是什么。
解答：
软件：
从 Kubernetes v1.12 开始，CoreDNS 是推荐的 DNS 服务器。
主要工作原理：
当使用 Deployment 运行 CoreDNS，则该 Deployment 通常会向外暴露为一个具有 静态 IP 地址 Kubernetes 服务。 kubelet 使用 --cluster-dns=<DNS 服务 IP> 标志将 DNS 解析器的信息传递给每个容器。
题目：
5. 描述configmap的功能，在容器中有几种使用方式
解答：
功能：
核心用途就是容器和配置的分离解耦。
如启用一个mysql容器，mysql容器重要的文件有两部分,一部分为存储数据文件,一部分为配置文件my.cnf，存储数据可以用持久存储实现和容器的分离解耦，配置文件也能够实现和容器的分离解耦,也就是说mysql容器能够直接读取并使用预先配置好的配置文件(而不是使用容器中默认自带的配置文件)。这就是configMap的功能。
ConfigMap 用于保存配置数据的键值对，可以用来保存单个属性，也可以用来保存配置文件。ConfigMap 跟 secret 很类似，但它可以更方便地处理不包含敏感信息的字符串。
使用方式：
ConfigMap 可以通过三种方式在 Pod 中使用
1.环境变量方式
2.volume挂载方式(一般都是用这个,支持热更新）
3.设置容器命令行参数
Ø 用环境变量：
1.[root@master-01 configmap]# kubectl create configmap env-config --from-literal=log_level=INFO
2.configmap/env-config created
3.[root@master-01 configmap]# kubectl create configmap special-config --from-literal=special.how=very --from-literal=special.type=charm
4.configmap/special-config created
Ø 用作命令行参数：
将 ConfigMap 用作命令行参数时，需要先把 ConfigMap 的数据保存在环境变量中，然后通过 $(VAR_NAME) 的方式引用环境变量。
Ø volume挂载方式（支持动态更新）：
configmap 挂载文件时，会先覆盖掉挂载目录，然后再将 congfigmap 中的内容作为文件挂载进行。如果想不对原来的文件夹下的文件造成覆盖，只是将 configmap 中的每个 key，按照文件的方式挂载到目录下，可以使用 subpath 参数。
题目：
6. 网上查询资料，描述secret资源对象的特点和用法，以及与configmap的差异。
解答：
Secret 是一种包含少量敏感信息例如密码、token 或 key 的对象。这样的信息可能会被放在 Pod spec 中或者镜像中；将其放在一个 secret 对象中可以更好地控制它的用途，并降低意外暴露的风险。用户可以创建 secret，同时系统也创建了一些 secret。
要使用 secret，pod 需要引用 secret。Pod 可以用两种方式使用：
Ø secret：作为 volume 中的文件被挂载到 pod 中的一个或者多个容器里
Ø 或者当 kubelet 为 pod 拉取镜像时使用。
差异：
比较之下，Configmap可以通过多种方式配置Pod中的容器，Configmap可以暴露给Pod，被挂载的 ConfigMap 内容会被自动更新。
题目：
7. Pod内对容器的健康检查有哪两种，各自的作用是什么？
解答：
LivenessProbe探针：
用于判断容器是否存活，即Pod是否为running状态，如果LivenessProbe探针探测到容器不健康，则kubelet将kill掉容器，并根据容器的重启策略是否重启，如果一个容器不包含LivenessProbe探针，则Kubelet认为容器的LivenessProbe探针的返回值永远成功。
ReadinessProbe探针：
用于判断容器是否启动完成，即容器的Ready是否为True，可以接收请求，如果ReadinessProbe探测失败，则容器的Ready将为False，控制器将此Pod的Endpoint从对应的service的Endpoint列表中移除，从此不再将任何请求调度此Pod上，直到下次探测成功。
题目：
8. 健康检查有哪几种探测方式，描述每种探测方式的用法示例（网上查询资料）
解答：
探测方式：
每种探测机制支持三种健康检查方法，分别是命令行exec，httpGet和tcpSocket，其中exec通用性最强，适用与大部分场景，tcpSocket适用于TCP业务，httpGet适用于web业务。
Ø exec ：提供命令或shell的检测，在容器中执行命令检查，返回码为0健康，非0异常
Ø httpGet：http协议探测，在容器中发送http请求，根据http返回码判断业务健康情况
Ø tcpSocket：tcp协议探测，向容器发送tcp建立连接，能建立则说明正常
用法示例：
exec：
Ø 许多应用程序运行过程中无法检测到内部故障，如死锁，出现故障时通过重启业务可以恢复，kubernetes提供liveness在线健康检查机制，我们以exec为例，创建一个容器启动过程中创建一个文件/tmp/liveness-probe.log，10s后将其删除，定义liveness健康检查机制在容器中执行命令ls -l /tmp/liveness-probe.log，通过文件的返回码判断健康状态，如果返回码非0，暂停20s后kubelet会自动将该容器重启。
httpGet
Ø httpGet probe主要主要用于web场景，通过向容器发送http请求，根据返回码判断容器的健康状态，返回码小于4xx即表示健康，如下定义一个nginx应用，通过探测http://<container>:port/index.html的方式判断健康状态
tcpSocket
Ø tcpsocket健康检查适用于TCP业务，通过向指定容器建立一个tcp连接，可以建立连接则健康检查正常，否则健康检查异常，依旧以nignx为例使用tcp健康检查机制，探测80端口的连通性
题目：
9. 描述namespace的主要功能和作用，以及namespace的隔离程度
解答：
主要功能和作用：
Linux 内核实现 namespace 的一个主要目的就是实现轻量级虚拟化(容器)服务。在同一个 namespace 下的进程可以感知彼此的变化，而对外界的进程一无所知。这样就可以让容器中的进程产生错觉，认为自己置身于一个独立的系统中，从而达到隔离的目的。也就是说 linux 内核提供的 namespace 技术为 docker 等容器技术的出现和发展提供了基础条件。
隔离程度：
我们可以从 docker 实现者的角度考虑该如何实现一个资源隔离的容器。比如是不是可以通过 chroot 命令切换根目录的挂载点，从而隔离文件系统。为了在分布式的环境下进行通信和定位，容器必须要有独立的 IP、端口和路由等，这就需要对网络进行隔离。同时容器还需要一个独立的主机名以便在网络中标识自己。接下来还需要进程间的通信、用户权限等的隔离。最后，运行在容器中的应用需要有进程号(PID)，自然也需要与宿主机中的 PID 进行隔离。也就是说这六种隔离能力是实现一个容器的基础。下图为linux 内核的 namespace 特性为我们提供的隔离能力：
题目：
10. 对应用的资源限制在k8s中有几个层级的设置，分别举例说明
解答：
对应用的资源限制在k8s中有两个层级，分别是容器级别的资源限制、Pod/Container级别的全局默认资源限制。
容器级别的资源限制：
Pod/Container级别的全局默认资源限制
题目：
11. 资源限制中，request和limit分别是什么作用？如果只设置limit不设置request，系统的行为是怎样的？
解答：
作用：
Ø Request: 容器使用的最小资源需求，作为容器调度时资源分配的判断依赖。只有当节点上可分配资源量>=容器资源请求数时才允许将容器调度到该节点。但Request参数不限制容器的最大可使用资源。
Ø Limit: 容器能使用资源的资源的最大值，设置为0表示使用资源无上限。
Request能够保证Pod有足够的资源来运行，而Limit则是防止某个Pod无限制地使用资源，导致其他Pod崩溃。两者之间必须满足关系: 0<=Request<=Limit<=Infinity (如果Limit为0表示不对资源进行限制，这时可以小于Request)
行为：
若不配置 request，调度器就无法感知节点资源使用情况，无法做出合理的调度决策，可能会造成调度不合理，引起节点状态混乱。
