• pyhhou
    2022-07-21
    思考题 1. 可以把 Pod 看作是介于容器之上的一层抽象,之所以需要这一层抽象是因为容器与容器之间有着不确定的关系,有的容器需要与彼此隔离,而有的容器却需要彼此交互。当容器规模增大,容器之间的作用关系就会变得极其复杂,难于管理。Pod 的出现就是为了解决容器管理的问题,让大规模应用下的容器编排变得更加清晰有序,易于维护 2. 不管是容器还是 Pod,都是虚拟概念。把普通进程或应用加上权限限制就成了容器,再把容器加上权限限制就成了 Pod。说白了,就是不断地抽象封装,这也是软件中解决复杂问题的唯一手段。容器之于Pod,就好比 线程之于进程、函数之于类、文件之于文件夹等等

    作者回复: awesome

    
    58
  • 三溪
    2022-07-27
    我这里补充下个人遇到的坑,希望对大家有所帮助! 当你使用kubectl apply -f指定YAML文件来创建pod时,只要你spec.containers.image里面的tag是latest,那么无论你的imagePullpolicy策略是什么,无论本地是否已存在该镜像文件,一定会先联网查询镜像信息,如果此时正好是私网无法连接互联网时,那么pod就会直接创建失败,你使用describe查询时报错也是无法拉取镜像。 只要tag不是latest,比如stable或者1.23什么的具体版本,本地已存在对应镜像文件,这时设置为IfNotPresent和Never才会生效,就可以在私网环境下愉快地离线创建pod。

    作者回复: awesome

    共 3 条评论
    25
  • 江湖十年
    2022-07-18
    imagePullPolicy 默认值并非 IfNotPresent,而是 Always: ➜ kubectl explain pod.spec.containers.imagePullPolicy KIND: Pod VERSION: v1 FIELD: imagePullPolicy <string> DESCRIPTION: Image pull policy. One of Always, Never, IfNotPresent. Defaults to Always if :latest tag is specified, or IfNotPresent otherwise. Cannot be updated. More info: https://kubernetes.io/docs/concepts/containers/images#updating-images

    作者回复: Defaults to Alwaysif :latest tag is specified。 只有lastest才是always。

    共 2 条评论
    15
  • 一步
    2022-07-18
    container 对象. env:定义 Pod 的环境变量 ------------- 这里 不应该是 container 的环境变量吗?

    作者回复: 抱歉,不小心手误了,确实,它属于container字段,是容器的环境变量。

    
    10
  • Frank
    2022-07-20
    老师 ,一般情况下,pod里只定义一个容器吗? 还是可以定义多个容器。 它们之间没有什么区别吗?

    作者回复: 一般是一个容器,但因为containers是一个数组,里面是可以有多个容器的。 Pod里的多个容器共享IP地址、存储卷、进程空间,pod就类似逻辑主机、虚拟机了,这些容器就可以像在主机里一样协同工作。

    共 4 条评论
    8
  • Apple_d39574
    2022-11-28 来自北京
    您好,想问一下,为什么要定义容器启动时要执行的命令?不设置会怎么样?

    作者回复: 因为容器本质上就是一个应用程序,没有命令该如何启动应用呢?想清楚这一点应该就能够理解了吧。

    
    6
  • Guder
    2022-07-19
    感觉pod有点像是docker-compose

    作者回复: 是的,不过尽量不要把docker的经验套在Kubernetes上,容易混淆。

    
    6
  • 咩咩咩
    2022-07-18
    1.若直接使用容器来管理应用,只能一个个容器去调度。应用之间一般都有进程和进程组的关系,而容器又只是单进程模型,无法管理多个进程 2.Pod是一组共享了某些资源的容器,只是一个逻辑概念

    作者回复: great

    
    5
  • 摊牌
    2022-07-18
    个人观点,不知道对不对,我觉得pod就应该叫做k8s自己的容器,如果没有pod, k8s直接调度容器对象,比如docker, 那它就永远要依赖docker; 如果k8s不对容器包装一下,没有类似pod这种粒度的话,k8s就必须选择一种现有容器技术,限制了其现在和未来的灵活性。所以,于公于私,构建pod这个基本调度单元是非常明智的选择,将来如果有新的容器技术代替了docker,但是k8s的基本单元永远是pod

    作者回复: great,中间层的思想。

    
    4
  • bjdz
    2022-10-28 来自上海
    向老师请教一个问题,被折磨坏了, docker images 显示本地是有 busybox:stable-glibc 这个版本的,yaml文件中的 imagePullPolicy: IfNotPresent,image: busybox:stable-glibc, 根据这个yaml文件创建pod,显示 pod/busybox created,但是 kubectl logs busybox,就显示镜像拉取失败 Error from server (BadRequest): container "busybox" in pod "busybox" is waiting to start: trying and failing to pull image 不明白为什么本地已经有镜像了,且不是最新的tag,为什么还要去拉取镜像? get pod报错:busybox 0/1 CrashLoopBackOff 7 (4m47s ago) 22m Events: Normal Scheduled 28m default-scheduler Successfully assigned default/busybox to minikube Warning Failed 24m kubelet Failed to pull image "busybox:stable-glibc": rpc error: code = Unknown desc = context canceled Warning Failed 24m (x2 over 24m) kubelet Error: ErrImagePull Warning Failed 24m kubelet Failed to pull image "busybox:stable-glibc": rpc error: code = Unknown desc = error pulling image configuration: Get "xxx": net/http: TLS handshake timeout Normal BackOff 24m (x2 over 24m) kubelet Back-off pulling image "busybox:stable-glibc" Warning Failed 24m (x2 over 24m) kubelet Error: ImagePullBackOff Normal Pulling 24m (x3 over 28m) kubelet Pulling image "busybox:stable-glibc" Normal Pulled 21m kubelet Successfully pulled image "busybox:stable-glibc" in 2m20.001262902s Normal Created 20m (x4 over 21m) kubelet Created container busybox Normal Started 20m (x4 over 21m) kubelet Started container busybox Normal Pulled 20m (x3 over 21m) kubelet Container image "busybox:stable-glibc" already present on machine Warning BackOff 2m55s (x86 over 21m) kubelet Back-off restarting failed container
    展开

    作者回复: 要看pod被调度到哪个节点上运行,本地有,不代表节点上一定有,注意Kubernetes是集群管理系统,不要把本地和集群弄混了。

    
    3