网站验收技术指标,wordpress始终无法登录,视觉设计部是干什么的,网站开发百度百科比如#xff0c;凡是调度、网络、存储#xff0c;以及安全相关的属性#xff0c;基本上是Pod 级别的。
这些属性的共同特征是#xff0c;它们描述的是“机器”这个整体#xff0c;而不是里面运行的“程序”。比如#xff0c;配置这个“机器”的网卡#xff08;即#…比如凡是调度、网络、存储以及安全相关的属性基本上是Pod 级别的。
这些属性的共同特征是它们描述的是“机器”这个整体而不是里面运行的“程序”。比如配置这个“机器”的网卡即Pod的网络定义配置这个“机器”的磁盘即Pod的存储定义配置这个“机器”的防火墙即Pod的安全定义。更不用说这台“机器”运行在哪个服务器之上即Pod的调度
NodeSelector是一个供用户将Pod与Node进行绑定的字段HostAliases定义了Pod的hosts文件比如/etc/hosts里的内容
docker run里的-it-i即stdin-t即tty参数。
如果你还是不太理解它们俩的作用的话可以直接认为tty就是Linux给用户提供的一个常驻小程序用于接收用户的标准输入返回操作系统的标准输出。当然为了能够在tty中输入信息你还需要同时开启stdin标准输入流
凡是跟容器的Linux Namespace相关的属性也一定是Pod 级别的如shareProcessNamespacetrue凡是Pod中的容器要共享宿主机的Namespace也一定是Pod级别的定义
容器级别的字段
首先是ImagePullPolicy字段ImagePullPolicy的值默认是Always即每次创建Pod都重新拉取一次镜像而如果它的值被定义为Never或者IfNotPresent则意味着Pod永远不会主动拉取这个镜像或者只在宿主机上不存在这个镜像时才拉取如果镜像是latest那么每次肯定是取最新的其次是Lifecycle字段。它定义的是Container Lifecycle Hooks。顾名思义Container Lifecycle Hooks的作用是在容器状态发生变化时触发一系列“钩子”。Pod对象的Status字段还可以再细分出一组Conditions。这些细分状态的值包括PodScheduled、Ready、Initialized以及Unschedulable。它们主要用于描述造成当前Status的具体原因是什么 Volumn Volume叫作Projected Volume你可以把它翻译为“投射数据卷”这些特殊Volume的作用是为容器提供预先定义好的数据 到目前为止Kubernetes支持的Projected Volume一共有四种
Secret
ConfigMap
Downward API
ServiceAccountToken。
secret对象 Secret对象要求这些数据必须是经过Base64转码的以免出现明文密码的安全隐患在真正的生产环境中你需要在Kubernetes中开启Secret的加密插件增强数据的安全性 卷的核心是一个目录其中可能包含一些数据pod中的容器可以访问该目录。该目录的形成方式、支持它的介质以及它的内容由所使用的特定卷类型决定。 要使用卷需要在.spec.volumes中指定要为pod提供的卷并在.spec.containers[*].volumeMounts中声明加载这些卷到容器的位置。容器中的进程会看到一个文件系统视图该视图由容器镜像的初始内容以及容器中装入的卷如果已定义的话组成。该进程会看到一个root文件系统它最初与容器镜像的内容相匹配。如果允许对该文件系统层次结构中的任何写入都会影响该进程在执行后续文件系统访问时查看的内容。在镜像中的指定路径上加载卷。对于pod中定义的每个容器必须单独指定容器使用的每个卷的加载位置 各种不同类型的卷
与Secret类似的是ConfigMap它与Secret的区别在于ConfigMap保存的是不需要加密的、应用所需的配置信息。 获取pod信息 接下来是Downward API它的作用是让Pod里的容器能够直接获取到这个Pod API对象本身的信息Downward API能够获取到的信息一定是Pod里的容器进程启动之前就能够确定下来的信息 授权 像这样的Service Account的授权信息和文件实际上保存在它所绑定的一个特殊的Secret对象里的。这个特殊的Secret对象就叫作ServiceAccountToken。任何运行在Kubernetes集群上的应用都必须使用这个ServiceAccountToken里保存的授权信息也就是Token才可以合法地访问API Server。 这种把Kubernetes客户端以容器的方式运行在集群里然后使用default Service Account自动授权的方式被称作“InClusterConfig”也是我最推荐的进行Kubernetes API编程的授权方式。 健康检查 在Kubernetes中你可以为Pod里的容器定义一个健康检查“探针”Probe。这样kubelet就会根据这个Probe的返回值决定这个容器的状态而不是直接以容器镜像是否运行来自Docker返回的信息作为依据。 在容器启动5 s后开始执行initialDelaySeconds: 5每5 s执行一次periodSeconds: 5 恢复机制 Pod的恢复过程永远都是发生在当前节点上而不会跑到别的节点上去 Pod恢复机制也叫restartPolicy。它是Pod的Spec部分的一个标准字段pod.spec.restartPolicy默认值是Always即任何时候这个容器发生了异常它一定会被重新创建。 而如果你想让Pod出现在其他的可用节点上就必须使用Deployment这样的“控制器”来管理Pod哪怕你只需要一个Pod副本 readinessProbe的字段。虽然它的用法与livenessProbe类似但作用却大不一样。readinessProbe检查结果的成功与否决定的这个Pod是不是能被通过Service的方式访问到而并不影响Pod的生命周期。 如何追加信息到Pod 比如开发人员只需要提交一个基本的、非常简单的Pod YAMLKubernetes就可以自动给对应的Pod对象加上其他必要的信息比如labelsannotationsvolumes等等。而这些信息可以是运维人员事先定义好的。 运维人员就可以定义一个PodPreset对象。在这个对象中凡是他想在开发人员编写的Pod里追加的字段都可以预先定义好 PodPreset里定义的内容只会在Pod API对象被创建之前追加在这个对象本身上而不会影响任何Pod的控制器的定义
