本章主题“实践出真知”，如果想要尽可能的熟悉相关知识，上手实践是检验的最好标准。
简介； k8s可能大家都不陌生，相当于一个操作系统，可以对各种资源进行调度和安排，你只需将应用部署上去，他可以根据你创建的资源类型以及相应的一些应用需求进行安排和调度。 k8s中的各类对象：
- 资源对象：Pod、ReplicaSet、ReplicationController、Deployment、 StatefulSet、DaemonSet、Job、CronJob、HorizontalPodAutoscaling
- 配置对象：Node、Namespace、Service、Secret、ConfigMap、Ingress、Label、ThirdPartyResource、 ServiceAccount
- 存储对象：Volume、Persistent Volume
- 策略对象：SecurityContext、ResourceQuota、LimitRange
1.总述： 下图简单的描述他们之间的层次关系，了解他们之间的关系在排查问题时能够“顺藤摸瓜”发现问题。
deployment根据Pod的标签关联到Pod,是为了管理pod的生命周期 service根据Pod的标签关联到pod,是为了让外部访问到pod,给pod做负载均衡
pod运行相关问题查看deployment的日志，服务访问相关的问题查看对应的service的日志。
pod的yaml文件
Name: *资源名称*
Namespace:* 命名空间*
Priority: *优先级*
Node:* 资源所在的节点*
**Labels**: app=
pod-template-hash=
tier=database
version=
Annotations:
Status: Running
IP:
Controlled By:
Containers:
Limits:
cpu: 1
memory: 1000Mi
Requests:
cpu: 20m
memory: 100Mi
Environment: <none>
*Mounts*: /data from N-pvc (rw,path="redis-data")
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
*Volumes*:
N-pvc:
Type: PersistentVolumeClaim (a reference to a PersistentVolumeClaim in the same namespace)
ClaimName: N-pvc
ReadOnly: false
Service的yaml文件
Name: *资源名称*
Namespace: *命名空间*
**Selector**: app=,pod-template-hash=
**Labels**: app=
pod-template-hash=
Annotations:
Controlled By: Deployment/
Replicas: 0 current / 0 desired Pods Status: 0 Running / 0 Waiting / 0 Succeeded / 0 Failed
Pod Template:*pod的描述*
Labels: app=
pod-template-hash=
Annotations:
Service Account: *应用名称*
Containers:
installer:
Image:
Port: <none>
Host Port: <none>
Environment: <none>
Mounts: *挂载的位置*(rw)
Volumes:
host-time:
Type: (bare host directory volume)
Path: *路径*
HostPathType:
Deployment的yaml文件
Name: *资源名称*
Namespace: *命名空间*
Labels: app=
Annotations:
Selector: app=
Replicas: 1 desired | 1 updated | 1 total | 1 available | 0 unavailable StrategyType:
MinReadySeconds: 0
RollingUpdateStrategy: 25% max unavailable, 25% max surge
Pod Template:
Labels: app=
Annotations:
Service Account: ks-installer
Containers:
installer:
Image:
Port: <none>
Host Port: <none>
Environment: <none>
Mounts:
Volumes:
host-time:
Type:
HostPath (bare host directory volume)
Path:
HostPathType:
熟悉k8s中的资源对象后，我们继续了解k8s中的配置对象：
首先Namespace，是命名空间，约定了资源对象的边界，使得不同的应用彼此在逻辑上隔离,使得不同的服务的管理之间隔离（参考微服务逻辑）。因此，在执行相应的命令时记住要指定对应的命名空间-n namespace，当不指定时，默认为default空间。集群中还有其他两个空间：
- default：service和app不指定命名空间，将被创建于此。
- kube-system：kubernetes系统组件使用。
- kube-public：公共资源使用。但实际上并不常用。 configmap是用来存K8s中资源对象的储配置文件，存储在etcd中。每个服务（应用）都拥有至少一个配置文件，来存储应用的相关配置信息. 注意：关于服务（应用）的网络路由配置信息主要集中在cm中，当发现网络相关问题首先考虑在此处排查。 关于集群中对象的网络信息：存在三种地址分别为NodeIP clusterIP podIP。
nodeIP:Node节点的IP地址，即物理网卡的IP地址。 clusterIP:Service的IP地址，此为虚拟IP地址。Service的IP地址，此为虚拟IP地址。外部网络无法ping通，只有kubernetes集群内部访问使用。 podIP:Pod的IP地址，即docker容器的IP地址，此为虚拟IP地址。同Service下的pod可以直接根据PodIP相互通信。
同时需要了解，kubectl get pod -o wide -A 可以查看到其中的IP即为每个pod的podIP信息。
通过
kubectl get svc -o wide -A 同样可以查看到service的描述。其中的type为service的类型，分为clusterIP、NodePort以及LoadBalance三种服务类型。这是将pod上所运行的服务暴露出去的三种方式，三种方式对应不同的设置。
通过kubectl escrib svc/ack-node-name -n kube-system 查看到service的配置，Endpoints: 这个标签即为该service对应的pod的IP地址。
综上：pod的podIP为虚拟内部地址，只是为了同一个service内的pod通信，要想不同service间的pod通信，必须借助service的clusterIP。service的clusterIP也是内部
虚拟地址，用于集群内的服务之间通信。并且service的IP地址是随着pod的状态改变而改变，如果想要访问就需要通过域名的设置来访问，集群内部支持默认的域名配置cluster.svc.xxx的方式访问.不知道，大家还记得上述的namespace的作用与否。namespace用来隔离不同的应用和服务，通过查看/ect/resolv.conf文件查看对应的配置。形如 namespace 域名 这样的形式。 如果想要自定义的域名，就要设置自定义的域名解析服务器。
三种网络间通信链路以及之间的关系如下图所示：
DNS的设置通过configmap配置对象进行设置，因此通过configmap（cm）查看相应的资源设置。
kubectl get cm -A
kubectl get cm/coredns -o yaml -n kube-system
kubectl describe cm/coredns -n kube-system
关于集群的DNS 对象的配置，对于DNS，想必大家都非常熟悉，如果不想要通过IP：port的方式访问服务，而是通过自定义的域名的方式访问服务，需要设置进行DNS解析的服务器地址。
这里需要注意，有两种访问方式，分别是在集群内部使用自定义域名方式访问不同的服务资源，以及在集群外通过自定义域名的方式访问集群内部的服务两种。
首先介绍在集群内部通过域名进行服务访问的设置： 1.首先在系统设置的相关NameSpace查看coredns的设置。 2.对配置内容进行更改以进行自定义域名解析服务的设置。（如果不想使用自定义的域名服务，使用集群自带的dns解析配置即可）
kubectl get cm/coredns -o yaml -n kube-system
data:
Corefile: |
.:53 {
log
errors
health {
lameduck 15s
}
ready
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods verified
ttl 30
fallthrough in-addr.arpa ip6.arpa
}
prometheus :9153
forward . /etc/resolv.conf
cache 30
loop
reload
loadbalance
}
xueqiu.com:53 {
errors
cache 30
forward . 172.16.1.42
}
snowballfinance.com:53 {
errors
cache 30
forward . 172.16.1.42
}
kind: ConfigMap
服务的类型为LoadBalance，且pod的DNSPolicy设置为ClusterFirst.+上述的DNS配置。
pod的几种DNSPolic：
在Kubernetes中，可以针对每个Pod设置DNS的策略，通过PodSpec下的dnsPolicy字段可以指定相应的策略，目前支持的策略如下：
Default: Pod继承所在宿主机的设置，也就是直接将宿主机的/etc/resolv.conf内容挂载到容器中。ClusterFirst: 默认的配置，所有请求会优先在集群所在域查询，如果没有才会转发到上游DNS。ClusterFirstWithHostNet: 和ClusterFirst一样，不过是Pod运行在hostNetwork:true的情况下强制指定的。None: 1.9版本引入的一个新值，这个配置忽略所有配置，以Pod的dnsConfig字段为准
PV与PVC的关系
k8s中的存储单元是pv，由pvc管理。但是手动创建pv和pvc比较麻烦，这时候就出现了可以动态、自动创建pv的storageclass。
storageclass是集群内的存储资源的描述，通过kubectl get sc -A 即可查看集群内现有的存储资源以及相应的状态.
其中包含
provisioner 声明提供者，当然该声明者需要事先创建。
通过创建pvc中的storageClassName 来将资源绑定，并且会自动绑定到对应声明者下面的存储，即为pv上。
1.kubectl cluster-info
2.kubectl get nodes -o wide
了解相应的对象以及其中的关系，从整体上掌握集群的相关信息：
集群的架构：
集群由master和node组成，可通过如下命令查看集群信息：
节点上的资源信息以及其上的pod相关内容可通过该命令查看
kubectl describe nodes/kubectl describe node node_name
其实，了解了集群的资源类型就已经掌握了集群的架构相关，无非是集群中不同的节点的任务和角色不同而已。
附赠：常用命令
kubectl get pod -A
kubectl get pod -n namespace -o yaml
kubectl get pod -n namespace -o wide
kubectl describe pod/pod_name -n namespace
kubectl logs -f pod/pod_name -n namespace
kubectl edit pod/pod_name -n namespace
