Kubernetes 学习笔记 权威指南第二&三章
1 etcd服务作为Kubernetes集群的主数据库，在安装Kubernetes各服务之前需要首先安装和启动
2 在多个Node组成的Kubernetes集群内，跨主机的容器间网络互通是Kubernetes集群能够正常工作的前提条件
3 创建资源用create 查询用get 查询详细信息describe 删除资源delete 无则创建有则更新apply 编辑运行中的资源edit
登录到容器：
查看容器日志：
若不指定容器，默认pod里的第一个容器
4 将集群上Pod的80端口映射到本地的8888端口
5 把Pod上的/etc/fstab复制到本地的/tmp目录
6 用户自定义插件的可执行文件名需要以“kubectl-”开头，复制到$PATH中的某个目录（如/usr/local/bin），然后就可以通过kubectl <plugin-name>运行自定义插件了
===========第三章
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中各应用实例在创建和运行的过程中，都具有固定的身份标识和独立的后端存储；还支持在运行时对集群规模进行扩容、保障集群的高可用等非常重要的功能
21 为RC快速创建service：
22 通过创建一个无Label Selector的Service来实现调用外部服务
23 Headless Service:不为Service设置ClusterIP（入口IP地址），仅通过Label Selector将后端的Pod列表返回给调用的客户端
24 StatefulSet就是使用Headless Service为客户端返回多个服务地址的
