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

为什么一般集群都要用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,当指定多个时,只有最后一个起效。

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

  1. 都可以指定shell或exec函数调用的方式执行命令;
  2. 当存在多个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         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这个域名上

```

 

 

 

 

 

你可能感兴趣的:(分布式)