1 云上的网络相关的：

网段不同，服务器也不一样，在运行当中突然中断，你不用考虑端口的事，这个大概是什么原因，排查的思路以及原因是什么？

①  **网络配置问题**：检查你的网络配置，确保所有的服务器都在正确的网段中。如果有任何配置错误，例如错误的子网掩码或网关，都可能导致网络中断。

②. **服务器问题**：检查你的服务器状态。如果服务器过载或者出现故障，也可能导致网络中断。你可以查看服务器的CPU、内存和磁盘使用情况，以及查看系统日志，看是否有任何异常。

③. **网络设备问题**：如果你的网络设备（如路由器或交换机）出现问题，也可能导致网络中断。你可以检查设备的状态，看是否有任何故障。

④ . **服务供应商问题**：如果你的云服务供应商出现问题，例如网络拥塞或者设备故障，也可能导致网络中断。你可以联系你的服务供应商，询问是否有任何已知的问题。

⑤ . **安全问题**：如果你的网络被攻击，例如DDoS攻击，也可能导致网络中断。你可以查看你的安全日志，看是否有任何异常。

在排查问题时，你可以使用各种网络诊断工具，例如ping、traceroute、netstat等，这些工具可以帮助你确定问题的位置。同时，你也可以查看你的系统和应用日志，这些日志可能包含有关问题的更多信息。

2 如何将一个应用从所有的东西传输到云上，保证他正常运行，你会怎么做，该怎么配置和调试

将一个应用迁移到云上并确保其正常运行涉及到多个步骤，包括应用的评估、迁移策略的选择、迁移的实施以及后续的优化和调试。以下是一种可能的步骤：

    应用评估：首先，你需要对你的应用进行全面的评估，了解其架构、依赖关系、数据量、性能需求等。这将帮助你确定最适合的云服务和迁移策略。

    选择迁移策略：根据你的应用特性和业务需求，你可以选择不同的迁移策略。例如，如果你的应用是无状态的，你可以选择重新部署；如果你的应用有大量的数据和复杂的依赖关系，你可能需要选择数据迁移或者应用迁移。

    迁移实施：在你选择了迁移策略后，你可以开始实施迁移。这可能包括创建新的云环境、迁移数据、配置网络和安全设置、部署应用等。

    优化和调试：迁移完成后，你需要对你的应用进行优化和调试以确保其在云环境中的性能。这可能包括调整应用的配置、优化数据库的性能、调整网络设置等。

具体的配置和调试步骤会根据你的应用和所选的云服务有所不同，例如：

如果你使用的是AWS，你可能需要使用AWS的管理控制台或者CLI工具进行配置和调试；

如果你使用的是Google Cloud，你可能需要使用Google Cloud Console或者gcloud命令行工具。

在调试过程中，你可能需要使用各种工具和技术，例如日志分析、性能监控、负载测试等，以帮助你找出和解决问题。你也可能需要参考云服务提供商的文档和社区资源，或者寻求专业的技术支持

3 问mysql数据库和orcal数据库有什么不一样区别，你们用的啥 。

1. 规模与用途：

   • MySQL通常用于中小型企业或Web应用程序，因其轻量级和易于管理的特性。
   • Oracle则更多地应用于大型企业级环境，提供强大的数据管理和分析能力。

2. 开放性与成本：

   • MySQL是开源的，可以免费使用，尽管Oracle公司拥有它，并提供了付费支持服务。
   • Oracle是一个商业数据库，需要购买许可证，成本较高。

3. 并发处理能力：

   • Oracle具有更高级的并发控制和事务处理能力，适合高负载的在线事务处理（OLTP）系统。
   • MySQL通过不同的存储引擎（如InnoDB）提供不同程度的并发支持。

4 问了一下磁盘分区的一些东西

一 kubectl这个命令执行的过程？(以部署nginx服务为例)

 1、kubectl发送了一个部署nginx的任务
  2、进入Master节点，进行安全认证，
  3、认证通过后，APIserver接受指令
  4、将部署的命令数据记录到etcd中
  5、APIserver再读取etcd中的命令数据
  6、APIserver找到scheduler（调度器），说要部署nginx
  7、scheduler（调度器）找APIserver调取工作节点数据。

8、APIserver调取etcd中存储的数据，并将数据发给scheduler。
    9、scheduler通过计算，比较找到适合部署nginx的最佳节点是node1，发送给APIserver。
    10、APIserver将要部署在node1的计划存储到etcd中。
    11、APIserver读取etcd中的部署计划，通知node1节点的kubelet部署容器
    12、kubelet根据指令部署nginx容器，kube-proxy为nginx容器创建网桥
    13、容器网桥部署完成后，kubelet通知APIserver部署工作完成。
    14、APIserver将部署状态存储到etcd当中，同时通知controller manager(控制器）有新活了
    15、controller manager向APIserver要需要监控容器的数据
    16、APIserver找etcd读取相应数据，同时通知kubelet要源源不断发送监控的数据
    17、APIserver将kubelet发送来的数据存储到etcd当中
    18、APIserver将etcd的数据返回给controller manager
    19、controller manager根据数据计算判断容器是否存在或健康

二 说一下PostStart、PreStop钩子？

    PostStart :在容器创建后立即执行。但是，并不能保证钩子将在容器ENTRYPOINT之前运行，因为没有参数传递给处理程序。
主要用于资源部署、环境准备等。不过需要注意的是如果钩子花费时间过长以及于不能运行或者挂起，容器将不能达到Running状
态。
    容器启动后执行，注意由于是异步执行，它无法保证一定在ENTRYPOINT之后运行。如果失败，容器会被杀死，并根据
RestartPolicy决定是否重启
    PreStop :在容器终止前立即被调用。它是阻塞的，意味着它是同步的，所以它必须在删除容器的调用出发之前完成。主要用于
优雅关闭应用程序、通知其他系统等。如果钩子在执行期间挂起，Pod阶段将停留在Running状态并且不会达到failed状态
容器停止前执行，常用于资源清理。如果失败，容器同样也会被杀死

三 添加、修改、删除标签的命令？

    kubectl label node node-1 app=nginx
    kubectl label node node-1 app=mycat --overwrite
    kubectl label node node-1 app

四 删除一个pod集群内部会发生什么？

    kube-apiserver会接受到用户的删除指令，默认有30秒时间等待优雅退出，超过30秒会被标记为死亡状态
此时Pod的状态是Terminating，Kubelet看到Pod标记为Terminating开始了关闭Pod的工作
    1、Pod从service的列表中被删除
    2、如果该Pod定义了一个停止前的钩子，其会在pod内部被调用，停止钩子一般定义了如何优雅结束进程
    3、进程被发送TERM信号（kill -14）
    4、当超过优雅退出时间时，Pod中的所有进程都很被发送SIGKILL信号（kill -9）

五 持久化的方式有哪些？

    EmptyDir（空目录）：没有指定要挂载宿主机上的某个目录，直接由Pod内保部映射到宿主机上。类似于docker中的manager
volume。
    Hostpath：将宿主机上已存在的目录或文件挂载到容器内部。类似于docker中的bind mount挂载方式。这种数据持久化方式，运用
场景不多，因为它增加了pod与节点之间的耦合。
    PersistentVolume（简称PV）：基于NFS服务的PV，也可以基于GFS的PV。它的作用是统一数据持久化目录，方便管理。

六 k8s集群节点需要关机维护，需要怎么操作？

   1 驱逐 node 节点上 pod
         kubectl drain k8s-node-01 --force --ignore-daemonsets
    2  关机
        init 0

七 生产中碰到过什么问题，故障排查思路，如何解决的？

1 故障归类
    Pod状态 一直处于 Pending
    Pod状态 一直处于 Waiting
    Pod状态 一直处于 ContainerCreating
    Pod状态 处于 ImagePullBackOff
    Pod状态 处于 CrashLoopBackOff
    Pod状态 处于 Error
    Pod状态 一直处于 Terminating
    Pod状态 处于 Unknown
2.排查故障的命令
    kubectl get pod <pod-name> -o yaml
    查看Pod详细信息
    kubectl describe pod <pod-name>
    查看容器日志
    kubectl logs <pod-name> [-c <container-name>]
3.故障问题与排查方法
    1）、Pod 一直处于 Pending状态
      Pending状态
    这个状态意味着，Pod 的 YAML 文件已经提交给 Kubernetes，API 对象已经被创建并保存在 Etcd 当中。但是，这个 Pod 里
    有些容器因为某种原因而不能被顺利创建。比如，调度不成功（可以通过 kubectl describe pod命令查看到当前 Pod 的事件，        进而判断为什么没有调度）。
      可能原因
    资源不足（集群内所有的 Node 都不满足该 Pod 请求的 CPU、内存、GPU 等资源）；HostPort 已被占用（通常推荐使用
    Service 对外开放服务端口）
      2）、Pod 一直处于 Waiting或 ContainerCreating状态
    1、镜像拉取失败比如，镜像地址配置错误、拉取不了国外镜像源（gcr.io）、私有镜像密钥配置错误、镜像太大导致拉取超时        （可以适当调整 kubelet 的 --image-pull-progress-deadline 和 --runtime-request-timeout 选项）等。
    2、CNI 网络错误，一般需要检查 CNI 网络插件的配置，比如：无法配置 Pod 网络、无法分配 IP 地址。
    3、容器无法启动，需要检查是否打包了正确的镜像或者是否配置了正确的容器参数。
    4、Failed create pod sandbox，查看kubelet日志，原因可能是磁盘坏道（input/output error）。
      3）、Pod 一直处于 ImagePullBackOff状态
    通常是镜像名称配置错误或者私有镜像的密钥配置错误导致。这种情况可以使用 docker pull来验证镜像是否可以正常拉取。
    如果私有镜像密钥配置错误或者没有配置，按下面检查：
    ①查询 docker-registry 类型的 Secret
    查看 docker-registry Secret
    kubectl get secrets my-secret -o yaml | grep 'dockerconfigjson:' | awk '{print $NF}' | base64 -d
    ②创建 docker-registry 类型的 Secret
    # 首先创建一个 docker-registry 类型的 Secret
    kubectl create secret docker-registry my-secret --docker-server=DOCKER_REGISTRY_SERVER --dockerusername=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL
    # 然后在 Deployment 中引用这个 Secret
    spec:
      containers:
      - name: private-reg-container
        image: <your-private-image>
      imagePullSecrets:
      - name: my-secret
    4）、Pod 一直处于 CrashLoopBackOff 状态
    CrashLoopBackOff 状态说明容器曾经启动了，但又异常退出。此时可以先查看一下容器的日志。
    通过命令 kubectl logs 和 kubectl logs --previous 可以发现一些容器退出的原因，比如：容器进程退出、健康检查失败退
    出、此时如果还未发现线索，还可以到容器内执行命令来进一步查看退出原因（kubectl exec cassandra – cat
    /var/log/cassandra/system.log），如果还是没有线索，那就需要 exec 登录该 Pod 所在的 Node 上，查看 Kubelet 或者
    Docker 的日志进一步排查。
    5）、Pod 处于 Error 状态
    通常处于 Error 状态说明 Pod 启动过程中发生了错误
        常见原因
    依赖的 ConfigMap、Secret 或者 PV 等不存在；请求的资源超过了管理员设置的限制，比如超过了 LimitRange 等；违反集
    群的安全策略，比如违反了 PodSecurityPolicy 等；容器无权操作集群内的资源，比如开启 RBAC 后，需要为 ServiceAccount
    配置角色绑定;
    6）、Pod 处于 Terminating 或 Unknown 状态
    1、从集群中删除该 Node。使用公有云时，kube-controller-manager 会在 VM 删除后自动删除对应的 Node。而在物理机部署的
    集群中，需要管理员手动删除 Node（如 kubectl delete node ）。
    2、Node 恢复正常。Kubelet 会重新跟 kube-apiserver 通信确认这些 Pod 的期待状态，进而再决定删除或者继续运行这些
    Pod。用户强制删除。用户可以执行 kubectl delete pods pod-name --grace-period=0 --force 强制删除 Pod。除非明确知道
    Pod 的确处于停止状态（比如 Node 所在 VM 或物理机已经关机），否则不建议使用该方法。特别是 StatefulSet 管理的 Pod，
    强制删除容易导致脑裂或者数据丢失等问题。
    3、Pod 行为异常，这里所说的行为异常是指 Pod 没有按预期的行为执行，比如没有运行 podSpec 里面设置的命令行参数。这一般
    是 podSpec yaml 文件内容有误，可以尝试使用 --validate 参数重建容器，比如:
    kubectl delete pod mypod 和 kubectl create --validate -f mypod.yaml，也可以查看创建后的 podSpec 是否是对的，
    比如：kubectl get pod mypod -o yaml，修改静态 Pod 的 Manifest 后未自动重建，Kubelet 使用 inotify 机制检测
    /etc/kubernetes/manifests 目录（可通过 Kubelet 的 --pod-manifest-path 选项指定）中静态 Pod 的变化，并在文件发生变
    化后重新创建相应的 Pod。但有时也会发生修改静态 Pod 的 Manifest 后未自动创建新 Pod 的情景，此时一个简单的修复方法是
    重启 Kubelet。
    Unknown 这是一个异常状态，意味着 Pod 的状态不能持续地被 kubelet 汇报给 kube-apiserver，这很有可能是主从节点
    （Master 和 Kubelet）间的通信出现了问题。

八 k8s环境下，怎么代码上线？

九 Pod的调度算法

    1 deployment全自动调度
        运行在哪个节点上完全由master的scheduler经过一系列的算法计算得出, 用户无法进行干预

    2 nodeselector定向调度
        1、指定pod调度到一些node上, 通过设置node的标签和deployment的nodeSelctor属性相匹配
        2、多个node有相同标签, scheduler 会选择一个可用的node进行调度
        3、nodeselector定义的标签匹配不上任何node上的标签， 这个pod是无法调度
        4、k8s给node预定义了一些标签， 通过kubectl describe node xxxx进行查看
        5、用户可以使用k8s给node预定义的标签

    3 NodeAffinity： node节点亲和性
        硬限制 ： 必须满足指定的规则才可以调度pod到node上
        软限制 ： 优先满足指定规则，调度器会尝试调度pod到node上， 但不强求

    4 PodAffinity：pod亲和与互斥调度
        根据在节点上正在运行的pod标签而不是节点的标签进行判断和调度
            亲和： 匹配标签两个pod调度到同一个node上
            互斥： 匹配标签两个pod不能运行在同一个node上

十 如何升级k8s新版本

    1、配置k8s国内yum源
    2、查找可更新版本
        yum list updates | grep 'kubeadm'   # kubeadm中包含kuberctl，所以kubectl不用升级
    3、升级kubeadm版本
        yum install -y kubeadm*
    4、查看新版本的容器镜像版本
         kubeadm config images list
    5、更换镜像下载地址
        MY_REGISTRY=registry.aliyuncs.com/google_containers
    6、拉取镜像
        ## 拉取镜像
            docker pull ${MY_REGISTRY}/k8s-gcr-io-kube-apiserver:v1.20.5
            docker pull ${MY_REGISTRY}/k8s-gcr-io-kube-controller-manager:v1.20.5
            docker pull ${MY_REGISTRY}/k8s-gcr-io-kube-scheduler:v1.20.5
            docker pull ${MY_REGISTRY}/k8s-gcr-io-kube-proxy:v1.20.5
            docker pull ${MY_REGISTRY}/k8s-gcr-io-etcd:3.3.10
            docker pull ${MY_REGISTRY}/k8s-gcr-io-pause:3.1
            docker pull ${MY_REGISTRY}/k8s-gcr-io-coredns:1.3.6
    7、打标签
        ## 添加Tag
            docker tag ${MY_REGISTRY}/k8s-gcr-io-kube-apiserver:v1.13.4 k8s.gcr.io/kube-apiserver:v1.13.4
            docker tag ${MY_REGISTRY}/k8s-gcr-io-kube-scheduler:v1.13.4 k8s.gcr.io/kube-scheduler:v1.13.4
            docker tag ${MY_REGISTRY}/k8s-gcr-io-kube-controller-manager:v1.13.4 k8s.gcr.io/kube-controller-manager:v1.13.4
            docker tag ${MY_REGISTRY}/k8s-gcr-io-kube-proxy:v1.13.4 k8s.gcr.io/kube-proxy:v1.13.4
            docker tag ${MY_REGISTRY}/k8s-gcr-io-etcd:3.2.24 k8s.gcr.io/etcd:3.2.24
            docker tag ${MY_REGISTRY}/k8s-gcr-io-pause:3.1 k8s.gcr.io/pause:3.1
            docker tag ${MY_REGISTRY}/k8s-gcr-io-coredns:1.2.6 k8s.gcr.io/coredns:1.2.6
    8、检测k8s新版本
            kubeadm upgrade plan
    9、查看各个节点状态
            kubectl get nodes -o wide
    10、升级k8s
            kubeadm upgrade apply 新版本号

   11、升级节点逐个升级
            1）设置节点不可调度
                kubectl drain 节点名称 --ignore-daemonsets
            2）查找可用的kubelet升级包
                yum list updates | grep 'kubelet'
            3）升级kubelet
                yum install -y kubelet-新版本号
            master节点运行时会报错
                在 master 节点上执行这个命令时，预计会出现下面这个错误，该错误是可以安全忽略的（因为 master 节点上有 static pod
            运行）：
            ode "master" already cordoned
            error: pods not managed by ReplicationController, ReplicaSet, Job, DaemonSet or StatefulSet (use --force to
            override): etcd-kubeadm, kube-apiserver-kubeadm, kube-controller-manager-kubeadm, kube-scheduler-kubeadm
           4）重启
            # 重新加载系统配置
             systemctl daemon-reload
            # 重启kubelet
             systemctl restart kubelet
            # 查看kubelet状态
             systemctl status kubelet