Kubernetes 学习笔记 权威指南第二&三章

Kubernetes 学习笔记 权威指南第二&三章

1 etcd服务作为Kubernetes集群的主数据库，在安装Kubernetes各服务之前需要首先安装和启动

2 在多个Node组成的Kubernetes集群内，跨主机的容器间网络互通是Kubernetes集群能够正常工作的前提条件

3 创建资源用create  查询用get  查询详细信息describe 删除资源delete  无则创建有则更新apply 编辑运行中的资源edit

若不指定容器，默认pod里的第一个容器

4 将集群上Pod的80端口映射到本地的8888端口

6 用户自定义插件的可执行文件名需要以“kubectl-”开头，复制到$PATH中的某个目录（如/usr/local/bin），然后就可以通过kubectl 运行自定义插件了

===========第三章

1 在Kubernetes系统中对长时间运行容器的要求是：其主程序需要一直在前台执行。对于无法改造为前台执行的应用，可以使用Supervisor辅助进行前台运行的功能。Supervisor提供了一种可以同时启动多个后台应用，并保持Supervisor自身在前台执行的机制，可以满足Kubernetes对容器的启动要求

2 属于同一个Pod的多个容器应用之间相互访问时仅需要通过localhost就可以通信

3 静态Pod总是由kubelet创建的，并且总在kubelet所在的Node上运行。静态Pod无法通过API Server直接管理，若是通过配置文件创建的静态Pod，可以通过修改配置文件来管理

4 同一个Pod中的多个容器能够共享Pod级别的存储卷Volume，下面是个挂载卷的示例：

这里设置的Volume名为app-logs，类型为emptyDir（也可以设置为其他类型，详见第1章对Volume概念的说明），挂载到tomcat容器内的/usr/local/tomcat/logs目录，同时挂载到logreader容器内的/logs目录

5  可以通过YAML配置文件或者直接使用kubectl create configmap命令行的方式来创建ConfigMap

6 通过环境变量使用configmap的值

通过volumeMount使用ConfigMap

7 ConfigMap必须在Pod之前创建；静态Pod无法引用ConfigMap；在Pod对ConfigMap进行挂载（volumeMount）操作时，在容器内部只能挂载为“目录”，无法挂载为“文件”；如果在该目录下原来还有其他文件，则容器内的该目录将被挂载的ConfigMap覆盖。

8 Downward API有什么价值呢？

在某些集群中，集群中的每个节点都需要将自身的标识（ID）及进程绑定的IP地址等信息事先写入配置文件中，进程在启动时会读取这些信息，然后将这些信息发布到某个类似服务注册中心的地方，以实现集群节点的自动发现功能。此时Downward API就可以派上用场了，具体做法是先编写一个预启动脚本或Init Container，通过环境变量或文件方式获取Pod自身的名称、IP地址等信息，然后将这些信息写入主程序的配置文件中，最后启动主程序

9 Pod的重启策略包括Always、OnFailure和Never，默认值为Always。

◎　Always：当容器失效时，由kubelet自动重启该容器。

◎　OnFailure：当容器终止运行且退出码不为0时，由kubelet自动重启该容器。

◎　Never：不论容器运行状态如何，kubelet都不会重启该容器。

10 每种控制器对Pod的重启策略要求如下。

◎　RC和DaemonSet：必须设置为Always，需要保证该容器持续运行。

◎　Job：OnFailure或Never，确保容器执行完成后不再重启。

◎　kubelet：在Pod失效时自动重启它，不论将RestartPolicy设置为什么值，也不会对Pod进行健康检查。

11 应用MyApp目前发布了v1与v2两个版本，用户希望MyApp的Pod副本数保持为3个，可以同时包含v1和v2版本的Pod，就可以用ReplicaSet来实现这种控制

12 Kubernetes内置节点标签中的key：

◎　kubernetes.io/hostname

◎　failure-domain.beta.kubernetes.io/zone

◎　failure-domain.beta.kubernetes.io/region

13 Pod的亲和与互斥

14 DaemonSet用于管理在集群中每个Node上仅运行一份Pod的副本实例

15 Cron Job的定时表达式，它基本上照搬了Linux Cron的表达式，区别是第1位是分钟而不是秒

16 init container与应用容器在本质上是一样的，但它们是仅运行一次就结束的任务，并且必须在成功执行完成后，系统才能继续执行下一个容器

17 更新deployment的镜像：set image 或 edit

18 在默认情况下，Deployment确保可用的Pod总数至少为所需的副本数量（DESIRED）减1，也就是最多1个不可用（spec.strategy.rollingUpdate.maxUnavailable=1）

Deployment确保Pod的总数最多比所需的Pod数多1个，也就是最多1个浪涌值（spec.strategy.rollingUpdate.maxSurge=1）

19 不鼓励更新Deployment的标签选择器，添加标签选择器是无法向后兼容的，这意味着新的标签选择器不会匹配和使用旧选择器创建的ReplicaSets和Pod，因此添加选择器将会导致所有旧版本的ReplicaSets和由旧ReplicaSets创建的Pod处于孤立状态（不会被系统自动删除，也不受新的ReplicaSet控制）

20 Kubernetes使用StatefulSet来搭建有状态的应用集群（MongoDB、MySQL等）。Kubernetes能够保证StatefulSet中各应用实例在创建和运行的过程中，都具有固定的身份标识和独立的后端存储；还支持在运行时对集群规模进行扩容、保障集群的高可用等非常重要的功能

22 通过创建一个无Label Selector的Service来实现调用外部服务

23 Headless Service:不为Service设置ClusterIP（入口IP地址），仅通过Label Selector将后端的Pod列表返回给调用的客户端

24  StatefulSet就是使用Headless Service为客户端返回多个服务地址的

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。