前言：
之前我们画过下面这张图，通过图我们可以看出ReplicaSet是维护Pod，而Deployment是维护ReplicaSet的。那么我们就从Pod入手，毕竟Pod是Kubernetes的基础，没有Pod其他的都没任何用。
Pod是Kubernetes的基础，我们如何动态扩展Pod的数量以及动态下线某Pod呢？通过官网我们可以看到，ReplicatSet、ReplicationController、Deployment都可以维护Pod的数量。下面我们详细从Pod开始详细介绍一下Kubernetes的核心。
一、ReplicationController
官网：https://kubernetes.io/docs/concepts/workloads/controllers/replicationcontroller/
通过官网我们可以看出ReplicationController能保证任何时间点都有固定数量的pod副本在运行，总而言之就是ReplicationController可以保证一个或者一组Pod一直处于可用状态。
上面的话可以换成：ReplicationController可以保证一定数量的Pod一直处于运行状态，一旦Pod副本数量小于设置的数量，就会立即创建Pod以达到设置的数量（减少了传统IT环境手工运维的工作），而且还能筛选出同一组Pod，通过官网我们可以看出是通过Label Selector来筛选的。
之前生成Pod的时候我们写过yml文件，现在我们也可以写一个yml文件来生成对应的Pod，当然这个yml文件不是我自己写的，官网都有例子，自己拿下来改吧改吧就行了。
apiVersion: v1
kind: ReplicationController
metadata:
name: nginx
spec:
replicas: 3
selector:
app: nginx
template:
metadata:
name: nginx
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80kind：表示要创建对象的类型；
spec.repicas：ReplicationController要管理的Pod的副本数；
spec.selectot：ReplicationController要管理的Pod的label，之前讲过label是key:value形式的；
spec.template：定义Pod的模板，当有Pod挂了数量达不到repicas的数量时会根据spec.template生成新的Pod，例如Pod名称、label以及Pod中运行的应用等；通过改变模板中镜像的版本，可以实现Pod的升级功能（滚动更新rolling-update）；
通过运行kubectl apply -f xxx.yml命令可以创建3个Pod，并且每个Pod都有相同的label（app:nginx），同时每个Pod都会运行一个nginx容器。如果某个Pod发生了问题，ReplicationController能够及时发现并创建新的Pod。
相应的命令：
创建Pod:kubectl apply -f xxx.yml
查看Pod：kubectl get pods -o wide
kubectl get rc
尝试删除一个pod：kubectl delete pods podName
查看所有的pod:kubectl get pods
删除所有的pod:kubectl delete -f xxx.yml
也可以动态对pod扩缩容：kubectl scale rc podName--replicas=5**注意：**可以看到官网建议在Deployment中用ReplicatSet来代替ReplicationController完成复制功能，下面就介绍一下ReplicatSet。
ReplicationController也简称为RC，ReplicatSet简称为RS。
二、ReplicaSet
官网：https://kubernetes.io/docs/concepts/workloads/controllers/replicaset/
ReplicaSet也是对Pod进行管理。通过官网我们可以看到在Kubernetes v1.2时，ReplicationController升级为另一个概念ReplicaSet，也就是说ReplicaSet是ReplicationController的升级版，官方解释就是下一代RC。
RS和RC没有本质的区别，kubectl中绝大多数作用于RC的命令同样能适用于RS.
RS和RC唯一的区别：RS支持基于集合的Label Selector，而RC只支持基于等式的Label Selector，这使得RS的功能更强。
我们来看一下RS创建Pod的yml文件：
apiVersion: apps/v1
kind: ReplicaSet
metadata:
name: frontend
labels:
app: guestbook
tier: frontend
spec:
# modify replicas according to your case
replicas: 3
selector:
matchLabels:
tier: frontend
matchExpressions:
- {key:tier,operator: In,values: [frontend]}
template:
metadata:
labels:
tier: frontend
spec:
containers:
- name: php-redis
image: gcr.io/google_samples/gb-frontend:v3通过上面可以看出，唯一不同的就是label selector的表达式不同
**注意：**一般情况下，我们很少单独使用RS，它主要是被Deployment这个更高的资源对象所使用，从而形成一整套Pod创建、删除、更新的编排机制。当我们使用Deloyment时，无须关心它是如何创建和维护RS的，这一切都是自动发生的，同时，也无须担心跟其他机制的不兼容问题（比如ReplicaSet不支持rolling-update（容器镜像动态升级）但Deployment支持，ReplicationController也支持）。
三、Deployment
官网：https://kubernetes.io/docs/concepts/workloads/controllers/deployment/
我们可以看到Deployments不仅可以声明和更新ReplicaSet也能声明和更新Pods。
Deployment相对于RC来讲最大的一个升级就是我们可以随时知道当前Pod部署的进度。
我们一般利用yml文件创建一个Deployment对象来生成对应的RS并完成Pod副本的创建。检查Deployment状态来看部署动作是否完成，也就是Pod副本数量是否达到设置的数量。
我们来看一下创建Deployment的yml文件：
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80该yml文件看起来跟RC的特别的相似，就个别地方不一样。
我们可以使用一下命令来查看对应的pod和deployment的创建情况：
kubectl apply -f xxx.yml
查看pod:kubectl get pods -o wide
kubectl get deployment
kubectl get rs
kubectl get deployment -o wide
直接更新imges版本：kubectl set image deployment deploymentName nginx=nginx:1.9.1注意： ReplicationController、ReplicaSet、Deployment都是Controller。
四、Label and Selectors
官网：https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/
通过上面的介绍就能看出来，lable就是给Pod打标签，key:value的形式，我们可以将具有相同label的Pod交给Select管理。
查看pod的label标签：kubectl get pods --show-labels五、Namespace
命名空间就是为了隔离不同的资源，比如Pod，Service，Deployment等。可以在输入命令的时候指定命名空间-n +空间名，如果不指定就会用默认的命名空间：default。
也可以用yml文件创建命名空间，文件格式如下：
apiVersion: v1
kind: Namespace
metadata:
name: myns当然还是使用kubectl apply -f xxx.yml来创建
其他的命令：
查看所有的namespace：kubectl get namespaces/ns
查看某命名空间下的pod：kubectl get pods -n namespaceName
查看某命名空间下的所有资源：kubectl get all -n namespaceName
查看所有命名空间下的pd:kubectl get pods --all-namespaces
查看默认空间下的pod:kubectl get pods在某命名空间下创建pod，主需要在yml文件中的metadata中加入namespace即可：
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod
namespace: namespaceName
spec:
containers:
- name: nginx-container
image: nginx
ports:
- containerPort: 80六、NetWork
（一）同一个Pod中的容器通信
通过官网的话我们可以看出，同一个Pod内的容器是共享网络ip和端口的，所以通信显然没问题。
如果不通过ip和端口而想通过容器名进行访问呢？就需要将所有pod中的容器加入到同一个容器的网络中，我们把该容器成为为pod的pause container。
（二）集群内Pod之间的通信
每个Pod都有自己独立的IP地址，这个IP地址能被Pod内的Container共享，那么集群内的Pod能通过这个独立的IP进行通信吗？
集群内Pod之间的通信可以分为两种情况，一个是Pod在同一台机器，另一个是Pod在不同的机器，通过实验可以发现这两种情况是都能通信的，这里就不放代码了，有兴趣的小伙伴可以私聊我，我单独发。
虽然是能通信，但是是什么来支持他们之间的通信呢？其实通过官网我们就能知道，是插件帮我们做的，帮我们做这个的插件很多，我们主要用的就是Calico，后面会针对这个详细介绍。
官网：https://kubernetes.io/docs/concepts/cluster-administration/networking/#the-kubernetes-network-model
（三）集群内Service-Cluster IP
虽然集群中的Pod能够相互通信，但是Pod是不稳定的，因为我们通过Deployment管理Pod时会对Pod进行扩缩容，这时Pod的地址是发生变化的，通过ip访问就不可靠了。这时Service的作用就出来了，我们给同一类Pod打上标签，组成Service，Service有固定的ip，它会自动跟其管理的Pod进行负载均衡，这样无论Pod怎么创建和销毁我们通可以通过Sercice的IP进行访问。
官网：https://kubernetes.io/docs/concepts/services-networking/service/
1、用yml直接创建pod，yml中类型还是Deployment；
2、创建service:
kubectl expose deployment whoami-deployment3、然后运行：kubectl get svc就会出现类型为Cluster IP的service，然后通过访问发现能访问，但是Cluster IP类型的网络只能集群内通信。
其他命令：
删除svc kubectl delete service whoami-deployment（四）Pod访问外部应用
直接访问就是了
（五）外部应用访问集群内的Pod
1、NodePort
也是Service的一种，简单来说就是外部应用能访问集群的物理主机IP，所以就是在集群中每台物理机器上暴露一个IP。
1、先创建pod，yml文件直接参考Deployment那个模块的就行；
2、然后创建NodePort类型的Service,名称最好和deployment保持一致。
kubectl delete svc serviceName
kubectl expose deployment serviceName --type=NodePort3、再运行kubectl get svc
上图中的32041就是物理主机对外暴露的端口，通过浏览器访问发现能访问。但是这样不好之处就是会占用物理主机的端口。
Service除了NodePort方式以外还有一种方式是LoadBalance，但是这种需要第三方云提供商支持具有约束性。下面就介绍一种更好的方法，Ingress网络。
2、Ingress
官网：https://kubernetes.io/docs/concepts/services-networking/ingress/
通过官网的介绍，我们可以看到Ingress能够帮助我们访问集群内的服务，而且还提供了负载均衡、本地终结SSL会话以及基于名称的虚拟主机等功能。
上面讲了通过Service的NodePort方式来让外部应用访问集群内的Pod，但是这种方案在生产中不推荐，因此就可以用Ingress网络，在外部应用和Service之间使用，外部访问Ingress网络，然后通过Ingress再访问Service，然后Service再映射到对应的Pod。是不是有种Nginx负载均衡转发的感觉。
Ingress网络需要Ingress Controller，这是官网的介绍，我理解的就是Ingress是一个概念，而Ingress Controller就是针对这个概念具体的应用。
外部访问集群内的服务，一般我们都会使用Nginx做负载均衡，而现在我们使用Ingress来做了负载均衡。其实有开源爱好者把Nginx和Ingress结合起来了，也就是Nginx Ingress Controller，可以参考对应的官网：https://kubernetes.github.io/ingress-nginx/。github地址：https://github.com/kubernetes/ingress-nginx；kubernete官网关于Ingress的说明：https://kubernetes.io/docs/concepts/services-networking/ingress/。
就像我们不用kubernetes时一样，我们安装Nginx然后在nginx.conf下配置对应的访问规则，而用了kubernetes以后我们总不能还是安装Nginx然后在nginx.conf继续配置吧，用了kubernetes我们就要整套都智能化。我们只需要 创建Nginx Ingress Controller以及对应的Ingress规则，而且这是一次性的，安装以后不用再安装，只需要改一下Ingress规则即可。
这里讲一下外界通过Ingress Nginx Controller访问tomcat的Pod具体步骤：
2.1、创建Ingress Nginx Controller
通过NGINX Ingress Controller的官网，我们能找到创建NGINX Ingress Controller的yml文件，由于yml文件的内容太多了，我这里就不复制出来了，大家可以根据地址自行下载：
或者直接github下载：https://github.com/kubernetes/ingress-nginx/blob/master/deploy/static/provider/baremetal/deploy.yaml
用以下命令创建Ingress Nginx Controller：
kubectl apply -f xxx.yml
查看：kubectl get all -n ingress-nginx注意： 镜像拉取需要较长的时间，这块注意一下哦
2.2、以HostPort的方式创建
以Deployment方式创建Ingress Nginx Controller的Pod，要想让外界访问可以通过Service的NodePort或者HostPord方式，这两种方式Nginx Ingress Controller的官网都有介绍（上图红色圈出来的地方： Bare-metal considerations就是介绍Service的NodePort、HostPord以及其他方式的入口）。官网推荐使用NodePort的方式，但是我们上面说了但是我们上面说了NodePort会占用物理机的端口，会在所有有Service的物理主机都对外暴露一个单独的端口。所以我这里选择了HostPort的方式，在Ingress Controller对应的物理机器上对外暴露一个port即可，由于Ingress Controller创建以后在哪台机器上不固定，所以我们可以指定在固定节点运行Ingress Nginx Controller的Pod；
2.2.1、使用HostPort方式运行
需要增加配置，在Ingress Nginx Controller对应的yml文件中加入hostNetWork:true：
2.2.2、给节点打上标签
kubectl label node w1 name=ingress
给节点w1打上name=ingress的标签，这里的w1是节点的别名；
然后在Ingress Nginx Controller对应的yml文件中加入nodeSelector：
2.2.3、检查端口占用
通过Ingress Nginx Controller对应的yml文件我们可以看到，Ingress Controller是通过80和443对外暴露的，所以要确保w1节点上的80和443端口没有被占用
查看w1的80和443端口有没有被占用：
lsof -i tcp:80
lsof -i tcp:4432.3、创建tomcat的pod和service
tomcat的pod对应的yml文件(容器对外暴露的是8080端口)：
apiVersion: apps/v1
kind: Deployment
metadata:
name: tomcat-deployment
labels:
app: tomcat
spec:
replicas: 1
selector:
matchLabels:
app: tomcat
template:
metadata:
labels:
app: tomcat
spec:
containers:
- name: tomcat
image: tomcat
ports:
- containerPort: 8080可以使用以下命令：
创建tomcat的pod:kubectl apply -f tomcat.yml
查看创建的pod:kubectl get podstomcat的service对应的yml文件(service对外暴露的是80端口，指向pod的8080端口)：
apiVersion: v1
kind: Service
metadata:
name: tomcat-service
spec:
ports:
- port: 80
protocol: TCP
targetPort: 8080
selector:
app: tomcat可以使用以下命令：
创建tomcat的service:kubectl apply -f tomcat-service.yml
查看创建的service:kubectl get svc2.4、创建Ingress以及定义转发规则
当然也是用yml的方式，官网有对应的yml文件还有对应的配置规则详细说明，我这里只是配置了最简单的，只要访问我的域名，我就映射到到tomcat-service的服务的80端口
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
name: nginx-ingress
spec:
rules:
- host: tomcat.jack.com
http:
paths:
- path: /
backend:
serviceName: tomcat-service
servicePort: 80可以使用如下的命令：
创建ingress:kubectl apply -f nginx-ingress.yaml
查看创建的ingress： kubectl get ingress
查看详情排查问题：kubectl describe ingress nginx-ingress2.5、访问
打开浏览器访问tomcat.jack.com，前提是你这个域名有公网地址这样才能解析出来，或者你自己在本地配置了dns解析，修改本地的host文件即可。
2.6、总结
如果以后想使用Ingress网络，其实只要定义ingress规则，service和pod即可，前提是保证nginx ingress controller已经配置好了。
