分布式集群的常见面试问题

为什么一般集群都要用3台服务器来组建

一台机器叫单机，不算分布式

两台机器组成的的集群，当有一台机器出现故障另一台机器并不能及时作出反应，况且两台机器当稳定性不一定要比单机更问题，实际场景中当

只有当有三台服务器是能实现zookeeper容错

LOOKING：当前Server不知道leader是谁，正在搜寻
LEADING：当前Server即为选举出来的leader
FOLLOWING：leader已经选举出来，当前Server与之同步

dockerfile的cmd和entrypoint有何异同

CMD

支持三种格式

CMD ["executable","param1","param2"] 使用 exec 执行，推荐方式；

CMD command param1 param2 在 /bin/sh 中执行，提供给需要交互的应用；

CMD ["param1","param2"] 提供给 ENTRYPOINT 的默认参数；

指定启动容器时执行的命令，每个 Dockerfile 只能有一条 CMD 命令。如果指定了多条命令，只有最后一条会被执行。

如果用户启动容器时候指定了运行的命令，则会覆盖掉 CMD 指定的命令

ENTRYPOINT

两种格式：

ENTRYPOINT ["executable", "param1", "param2"]

ENTRYPOINT command param1 param2（shell中执行）。

配置容器启动后执行的命令，并且不可被 docker run 提供的参数覆盖。

每个 Dockerfile 中只能有一个 ENTRYPOINT，当指定多个时，只有最后一个起效。

从上面的说明，我们可以看到有两个共同点：

都可以指定shell或exec函数调用的方式执行命令；
当存在多个CMD指令或ENTRYPOINT指令时，只有最后一个生效；

而它们有如下差异：

差异1：CMD指令指定的容器启动时命令可以被docker run指定的命令覆盖，而ENTRYPOINT指令指定的命令不能被覆盖，而是将docker run指定的参数当做ENTRYPOINT指定命令的参数。

差异2：CMD指令可以为ENTRYPOINT指令设置默认参数，而且可以被docker run指定的参数覆盖；

docker如何暴露容器端口

1.使用iptable
获得容器IP
//[container_name]为docker容器名称

docker inspect [container_name] | grep IPAddress

iptable转发端口
//例：将容器的8000端口映射到宿主机的8001端口

iiptables -t nat -A DOCKER -p tcp -dport 8001 -j DNAT --to-destination 192.169.1.1:8080

2.
docker commit -a "shijie32177" -m "centos with redis cluster" centos-redis centos-redis:v1
返回
sha256:c044f4f28a4805823dc30605df2b0d15e06ab00ba122db5d00db434266adbd80
docker run -d -p 1001:7001 -p 1002:7002 -p 1003:7003 -p 1004:7004 -p 1005:7005 -p 1006:7006 shijie32177/centos-redis
返回
b4a4c6d6cc688407aa4c102fc459875bc8e3bacdc4b2b1504daebccab522ea1d

- Deployment和ReplicationController的异同
```
Replication Controller为Kubernetes的一个核心内容，应用托管到Kubernetes之后，需要保证应用能够持续的运行，Replication Controller就是这个保证的key，主要的功能如下：

确保pod数量：它会确保Kubernetes中有指定数量的Pod在运行。如果少于指定数量的pod，Replication Controller会创建新的，反之则会删除掉多余的以保证Pod数量不变。

确保pod健康：当pod不健康，运行出错或者无法提供服务时，Replication Controller也会杀死不健康的pod，重新创建新的。

弹性伸缩：在业务高峰或者低峰期的时候，可以通过Replication Controller动态的调整pod的数量来提高资源的利用率。同时，配置相应的监控功能（Hroizontal Pod Autoscaler），会定时自动从监控平台获取Replication Controller关联pod的整体资源使用情况，做到自动伸缩。

滚动升级：滚动升级为一种平滑的升级方式，通过逐步替换的策略，保证整体系统的稳定，在初始化升级的时候就可以及时发现和解决问题，避免问题不断扩大。

++++++++++++++++++++++++++++++++++++++++++++++

Deployment同样为Kubernetes的一个核心内容，主要职责同样是为了保证pod的数量和健康，90%的功能与Replication Controller完全一样，可以看做新一代的Replication Controller。但是，它又具备了Replication Controller之外的新特性：

Replication Controller全部功能：Deployment继承了上面描述的Replication Controller全部功能。

事件和状态查看：可以查看Deployment的升级详细进度和状态。

回滚：当升级pod镜像或者相关参数的时候发现问题，可以使用回滚操作回滚到上一个稳定的版本或者指定的版本。

版本记录: 每一次对Deployment的操作，都能保存下来，给予后续可能的回滚使用。

暂停和启动：对于每一次升级，都能够随时暂停和启动。

多种升级方案：Recreate：删除所有已存在的pod,重新创建新的; RollingUpdate：滚动升级，逐步替换的策略，同时滚动升级时，支持更多的附加参数，例如设置最大不可用pod数量，最小升级间隔时间等等。

```

- k8s暴露服务的3种方式(ClusterIP, NodePort, LoadBalancer)
```
ClusterIP 方式

- kubernetes 默认就是这种方式，是集群内部访问的方式
spec:
clusterIP: 10.0.0.1
ports:
- name: http

- NodePort 方式
NodePort方式主要通过节点IP加端口的形式暴露端口
访问方式：protocol://:.

heapster 10.3.129.117 <nodes> 80:30003/TCP 14d

apiVersion: v1
kind: Service
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"creationTimestamp":"2017-05-24T06:38:16Z","labels":{"kubernetes.io/name":"heapster","plugin":"heapster"},"name":"heapster","namespace":"kube-system","resourceVersion":"173906247","selfLink":"/api/v1/namespaces/kube-system/services/heapster","uid":"91470fbb-404b-11e7-ba41-5254eec04736"},"spec":{"clusterIP":"10.3.129.117","externalTrafficPolicy":"Cluster","ports":[{"nodePort":30003,"port":80,"protocol":"TCP","targetPort":8082}],"selector":{"k8s-app":"heapster"},"sessionAffinity":"None","type":"NodePort"},"status":{"loadBalancer":{}}}
creationTimestamp: 2018-07-25T03:22:01Z
labels:
kubernetes.io/name: heapster
plugin: heapster
name: heapster
namespace: kube-system
resourceVersion: "789489505"
selfLink: /api/v1/namespaces/kube-system/services/heapster
uid: e56886a2-8fb9-11e8-acd2-5254171bf8db
spec:
clusterIP: 10.3.129.117
externalTrafficPolicy: Cluster
ports:
- nodePort: 30003
port: 80
protocol: TCP
targetPort: 8082
selector:
k8s-app: heapster
sessionAffinity: None
type: NodePort
status:
loadBalancer: {}

- LoadBalancer 方式
这种方式主要是利用其他第三方的LB暴露服务的，谷歌或者亚马逊的LB等等

kind: Service
apiVersion: v1
metadata:
name: my-service
spec:
selector:
app: MyApp
ports:
- protocol: TCP
port: 80
targetPort: 9376
clusterIP: 10.0.171.239
loadBalancerIP: 78.11.24.19
type: LoadBalancer
status:
loadBalancer:
ingress:
- ip: 146.148.47.155

- ExternalName 方式
这种方式主要是通过CNAME实现的，在kubernetes 1.7.x以及以上才支持这种方式，例如
kind: Service
apiVersion: v1
metadata:
name: my-service
spec:
selector:
app: MyApp
ports:
- protocol: TCP
port: 80
targetPort: 9376
clusterIP: 10.0.171.239
loadBalancerIP: 78.11.24.19
type: LoadBalancer
status:
loadBalancer:
ingress:
- ip: 146.148.47.155

访问时，kube-dns服务直接解析到指定的Cnamemy.database.example.com这个域名上

```