Kubernetes 学习笔记 权威指南第一章
1 虚拟机采用NAT的网络模式以便连接外网
2 在每个Pod中都运行着一个特殊的被称为Pause的容器，其他容器则为业务容器，这些业务容器共享Pause容器的网络栈和Volume挂载卷，因此它们之间的通信和数据交换更为高效，在设计时我们可以充分利用这一特性将一组密切相关的服务进程放入同一个Pod中
3 在Node上运行着Kubernetes的kubelet、kube-proxy服务进程，这些服务进程负责Pod的创建、启动、监控、重启、销毁，以及实现软件模式的负载均衡器。
4 在Master上运行着集群管理相关的一组进程kube-apiserver、kube-controller-manager和kube-scheduler，这些进程实现了整个集群的资源管理、Pod调度、弹性伸缩、安全控制、系统监控和纠错等管理功能
5 在Kubernetes集群中，只需为需要扩容的Service关联的Pod创建一个RC（Replication Controller），服务扩容以至服务升级等令人头疼的问题都迎刃而解
6 使用kubeadm快速安装一个Kubernetes集群
7 YAML文件中的kind属性用来表明此资源对象的类型，比如值为ReplicationController，表示这是一个RC；在spec一节中是RC的相关属性定义，比如spec.selector是RC的Pod标签选择器，即监控和管理拥有这些标签的Pod实例
RC会根据在spec.template中定义的Pod模板来生成一个新的Pod实例，spec.template.metadata.labels指定了该Pod的标签，这里的labels必须匹配之前的spec.selector，否则此RC每创建一个无法匹配Label的Pod，就会不停地尝试创建新的Pod，陷入恶性循环中
8 创建副本集： kubectl create -f ***.yaml
查看创建的rc: kubectl get rc 查看创建的pod:kubectl get pods 查看创建的服务：kubectl get svc
查看集群中有多少个node: kubectl get nodes 查看deployment信息 kubectl get deployments kubectl descibe deployments
查看某个Node的详细信息: kubectl describe node <node_name>
查看某个pod的详细信息:kubectl describe pod xxxx
修改某个pod的副本集个数为3： kubectl scale rc pod名称 --replicates=3
查看endpoints: kubectl get endpoints
查看service:kubectl get svc 服务名 -o yaml
定义Tomcat服务时没有指定targetPort，则默认targetPort与port相同。targetPort是容器内的端口，port属性则定义了Service的虚端口
查询命名空间：kubectl get namespaces
若资源属于某个命名空间，则在查询资源信息时，需要指定命名空间，否则kubectl只会到default空间中找此资源：kubectl get pod --namespace =***
查看容器日志：kubectl logs pod名称 -c 容器名 ：
给node打标签：
使用kubectl get pods -o wide命令可以验证Pod所在的Node
检查这个Deployment部署的历史记录: kubectl rollout history
回滚deployment：kubectl rollout undo deployment/deployment的name
通过scale实现扩容/缩容：
9 创建Service, service的名称要是唯一的
type=NodePort和nodePort=30001的两个属性表明此Service开启了NodePort方式的外网访问模式
10 在Kubernetes里，一个Pod里的容器与另外主机上的Pod容器能够直接通信
11 Kubernetes大部分常见的核心资源对象都归属于v1这个核心API， 比如Node、 Pod、 Service、Endpoints、 Namespace、 RC、 PersistentVolume等
12 在Master上通常还需要部署etcd服务， 因为Kubernetes里的所有资源对象的数据都被保存在etcd中。
13 Pod其实有两种类型：普通的Pod及静态Pod（Static Pod）。后者比较特殊，它并没被存放在Kubernetes的etcd存储里，而是被存放在某个具体的Node上的一个具体文件中，并且只在此Node上启动、运行。
14 每个Pod可以设置限额的计算资源有CPU与Memory两种，其中CPU的资源单位为CPU（Core）的数量，是一个绝对值而非相对值。在Kubernetes里通常以千分之一的CPU配额为最小单位，用m来表示。通常一个容器的CPU配额被定义为100～300m，即占用0.1～0.3个CPU。
Memory配额也是一个绝对值，它的单位是内存字节数
15 一个Label是一个key=value的键值对，其中key与value由用户自己指定。Label可以被附加到各种资源对象上，例如Node、Pod、Service、RC等
name=redis-slave env!=production name in（redis-master, redis-slave） name not in（php-frontend）
16 可以通过多个Label Selector表达式的组合实现复杂的条件选择，多个表达式之间用“，”进行分隔即可，几个条件之间是“AND”的关系
17 matchLabels用于定义一组Label，matchExpressions用于定义一组基于集合的筛选条件（包括In、NotIn、Exists和DoesNotExist）
如果同时设置了matchLabels和matchExpressions，则两组条件为AND关系
18 在Pod定义文件中使用NodeSelector这种标签调度策略，kube-scheduler进程可以实现Pod定向调度的特性
19 删除RC并不会影响通过该RC已创建好的Pod。为了删除所有Pod，可以设置replicas的值为0，然后更新该RC。另外，kubectl提供了stop和delete命令来一次性删除RC和RC控制的全部Pod。
20 Replica Set，官方解释其为“下一代的RC”，Replica Set与RC当前的唯一区别是，Replica Sets支持基于集合的Label selector，而RC只支持基于等式的Label Selector
21 通过改变RC里Pod模板中的镜像版本，可以实现Pod的滚动升级
22 Deployment在内部使用了Replica Set来实现目的，可以把它看作RC的一次升级，相对于RC的一个最大升级是我们可以随时知道当前Pod“部署”的进度
除了API声明与Kind类型等有所区别，Deployment的定义与Replica Set的定义很类似
23 Pod的管理对象，除了RC和Deployment，还包括ReplicaSet、DaemonSet、StatefulSet、Job等，分别用于不同的应用场景中，将在第3章进行详细介绍。
24 HPA有以下两种方式作为Pod负载的度量指标。
◎ CPUUtilizationPercentage。【CPU利用率=Pod当前CPU的使用量/它的Pod Request的值】
◎ 应用程序自定义的度量指标，比如服务在每秒内的相应请求数（TPS或QPS）。
如果目标Pod没有定义Pod Request的值，则无法使用CPUUtilizationPercentage实现Pod横向自动扩容
这个控制的目标对象为一个名为php-apache的Deployment里的Pod副本，当这些Pod副本的CPUUtilizationPercentage的值超过90%时会触发自动动态扩容行为，在扩容或缩容时必须满足的一个约束条件是Pod的副本数为1～10
25 StatefulSet从本质上来说，可以看作Deployment/RC的一个特殊变种
每个StatefulSet定义中都要声明它属于哪个Headless Service
Headless Service与普通Service的关键区别在于，它没有Cluster IP，如果解析Headless Service的DNS域名，则返回的是该Service对应的全部Pod的Endpoint列表。StatefulSet在Headless Service的基础上又为StatefulSet控制的每个Pod实例都创建了一个DNS域名
26 StatefulSet里的每个Pod都有稳定、唯一的网络标识，可以用来发现集群内的其他成员。假设StatefulSet的名称为kafka，那么第1个Pod叫kafka-0，第2个叫kafka-1，以此类推
比如一个3节点的Kafka的StatefulSet集群对应的Headless Service的名称为kafka，StatefulSet的名称为kafka，则StatefulSet里的3个Pod的DNS名称分别为kafka-0.kafka、kafka-1.kafka、kafka-3.kafka，这些DNS名称可以直接在集群的配置文件中固定下来
27 Kubernetes里的每个Service其实就是我们经常提起的微服务架构中的一个微服务。service与其后端Pod副本集群之间则是通过Label Selector来实现无缝对接的。RC的作用实际上是保证Service的服务能力和服务质量始终符合预期标准。
28 Kubernetes Service支持多个Endpoint，在存在多个Endpoint的情况下，要求每个Endpoint都定义一个名称来区分
29 在Kubernetes集群之外的节点访问Kubernetes集群之内的某个节点或者TCP/IP服务时，都必须通过Node IP通信。
Kubernetes里一个Pod里的容器访问另外一个Pod里的容器时，就是通过Pod IP所在的虚拟二层网络进行通信的，而真实的TCP/IP流量是通过Node IP所在的物理网卡流出的。
Cluster IP无法被Ping，因为没有一个“实体网络对象”来响应。Service的Cluster IP属于Kubernetes集群内部的地址，无法在集群外部直接使用这个地址
NodePort的实现方式是在Kubernetes集群里的每个Node上都为需要外部访问的Service开启一个对应的TCP监听端口，外部系统只要用任意一个Node的IP地址+具体的NodePort端口号即可访问此服务
nodePort:31002这个属性表明手动指定tomcat-service的NodePort为31002，否则Kubernetes会自动分配一个可用的端口。接下来在浏览器里访问http://<nodePortIP>:31002/，就可以看到Tomcat的欢迎界面了
30 Job控制Pod副本与RC等控制器的工作机制有以下重要差别：
1）Job所控制的Pod副本是短暂运行的，Job生成的Pod副本是不能自动重启的，CronJob，解决了某些批处理任务需要定时反复执行的问题
2）Job所控制的Pod副本的工作模式能够多实例并行计算
31 如果使用了资源配额管理，则Kubernetes无法将hostPath在宿主机上使用的资源纳入管理
32 网络存储：Persistent Volume（PV）和与之相关联的Persistent Volume Claim（PVC）
33 Annotation则是用户任意定义的附加信息，以便于外部工具查找。
34 Kubernetes ConfigMap资源对象专门用来保存配置参数的Map .Kubernetes提供了一种内建机制，将存储在etcd中的ConfigMap通过Volume映射的方式变成目标Pod内的配置文件，不管目标Pod被调度到哪台服务器上，都会完成自动映射。如果ConfigMap中的key-value数据被修改，则映射到Pod中的“配置文件”也会随之自动更新
