刚接触 k8s 涉及到端口到内容较多,容易混淆,这里整理如下: 目录 nodePort port targetPort containerPort 参考文章 nodePort nodePort 提供了集群外部客户端访问 Service 的一种方式,nodePort 提供了集群外部客户端访问 Service 的端口,通过 nodeIP:nodePort 提供了外部流量访问k8s集群中service的入口. 比如外部用户要访问k8s集群中的一个Web应用,那么我们可以配置对应service的type

k8s端口 kube-api 6443 kube-controller-manager 10252 kube-scheduler 10251 kubelet 10250 kube-proxy 10256 etcd  2379与client端交互   2380与etcd内部交互 service yaml文件里面的ports nodePort:30003   物理主机的端口,默认范围30000-32767,暴露给集群外面访问 port:80   service的端口 targetPort:3000 

系列目录 在编排kubernetes时,Deployment的Pod项有containerPort,Service文件里的port,targetPort, nodePort,这些pod概念有些时候可能会让人感到非常困惑,这里通过示例来简单介绍各种port的含义 apiVersion: extensions/v1beta1 kind: Deployment metadata: name: tomcat-deployment spec: replicas: 3 template: metadata:

注:本文使用的Traefik为1.x的版本 在生产环境中,我们常常需要控制来自互联网的外部进入集群中,而这恰巧是Ingress的职责. Ingress的主要目的是将HTTP和HTTPS从集群外部暴露给该集群中运行的服务.这与Ingress控制如何将外部流量路由到集群有异曲同工之妙.接下来,我们举一个实际的例子来更清楚的说明Ingress的概念. 首先,想象一下在你的Kubernetes集群中有若干个微服务(小型应用程序之间彼此通信).这些服务能够在集群内部被访问,但我们想让我们的用户从集群外部也

本文将帮助你厘清在Kubernetes中调试 deployment的思路.下图是完整的故障排查思路,如果你想获得更清晰的图片,请在公众号后台(RancherLabs)回复"troubleshooting". 当你希望在Kubernetes中部署一个应用程序,你通常需要定义三个组件: Deployment--这是创建名为Pods的应用程序副本的方法 Serivce--内部负载均衡器,将流量路由到Pods Ingress--可以描述流量如何从集群外部流向Service 接下来,我们通过图片

Kubernetes中Deployment部署故障排除 字符型思维导图 排查pod状态(带标签):kubectl get pods,是否有等待处理的pod? 是?kubectl describe pod <pod-name>,集群资源是否已经爆满? 是?增加更多的磁盘资源 否?您是否达到ResourceQuota限制? 是?放宽ResourceQuota限制,修改pod的规格. 否?是否挂载了PersistentVolumeClaim(PVC). 是?修复PersistentVolumeCla

ConfigMap 1.什么是 ConfigMap? ConfigMap 是用来存储配置文件的 Kubernetes 资源对象,配置对象存储在 Etcd 中,配置的形式可以是完整的配置文件.key/value 等形式. 2.ConfigMap 能带来什么好处? 传统的应用服务,每个服务都有自己的配置文件,各自配置文件存储在服务所在节点,对于单体应用,这种存储没有任何问题,但是随着用户数量的激增,一个节点不能满足线上用户使用,故服务可能从一个节点扩展到十个节点,这就导致,如果有一个配置出现变更,就

一:Pod 是什么 Pod是Kubernetes的最重要最基本的概念.它是能够被创建,调度和管理的最小部署单元.一个Pod代表集群中一个运行的进程. 二:Pod的组成 一个Pod由一个特殊的根容器Pause容器和若干个紧密相关的用户业务容器组成. Pause容器作为Pod的根容器,它的状态代表整个容器组的状态. Pod里的多个容器共享Pause容器的IP,共享Pause容器挂载的Volume. Kubernetes为每个Pod都分配了唯一的IP地址,称之为Pod IP,一个Pod里的多个容器共享

本文收录在容器技术学习系列文章总目录 1.Pod控制器 1.1 介绍 Pod控制器是用于实现管理pod的中间层,确保pod资源符合预期的状态,pod的资源出现故障时,会尝试 进行重启,当根据重启策略无效,则会重新新建pod的资源. 1.2 pod控制器有多种类型 ReplicationController(RC):RC保证了在所有时间内,都有特定数量的Pod副本正在运行,如果太多了,RC就杀死几个,如果太少了,RC会新建几个 ReplicaSet(RS):代用户创建指定数量的pod副本数量,确保

不过,我相信你在学习和使用 Kubernetes 项目的过程中,已经不止一次地想要问这样一个问题:为什么我们会需要 Pod? 是啊,我们在前面已经花了很多精力去解读 Linux 容器的原理.分析了 Docker 容器的本质,终于,“Namespace 做隔离,Cgroups 做限制,rootfs 做文件系统”这样的“三句箴言”可以朗朗上口了,为什么 Kubernetes 项目又突然搞出一个 Pod 来呢? 要回答这个问题,我们还是要一起回忆一下我曾经反复强调的一个问题:容器的本质到底是什么? 你

作为 Kubernetes 项目里最核心的编排对象,Pod 携带的信息非常丰富.其中,资源定义(比如 CPU.内存等),以及调度相关的字段.在本篇,我们就先从一种特殊的 Volume 开始,来帮助你更加深入地理解 Pod 对象各个重要字段的含义. 这种特殊的 Volume,叫作 Projected Volume,你可以把它翻译为“投射数据卷”. (备注:Projected Volume 是 Kubernetes v1.11 之后的新特性) 这是什么意思呢? 在 Kubernetes 中,有几种特

定义Pod的常用资源 pods.spec.containers - name    <string>   #containers 的名字 image    <string>  #镜像地址 imagePullPolicy    <string>  #如果标签是latest  就是Always(总是下载镜像)  IfNotPresent(先看本地是否有此镜像,如果没有就下载) Never (就是使用本地镜像) ports    <[]Object>  #是给对象

一.pod初体验 1.编辑k8s_pod.yml文件 [root@k8s-master ~]# cat k8s_pod.yml apiVersion: v1 kind: Pod metadata: name: nginx labels: app: web spec: containers: - name: nginx image: 10.0.128.0:5000/nginx:latest ports: - containerPort: 80 2.下载镜像并上传到私有仓库 [root@k8s-ma

一.共享容器IP地址 1.查看容器进程 [root@k8s-node1 ~]# docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 27d25a2ee024 10.0.128.0:5000/nginx:latest "nginx -g 'daemon off" 6 minutes ago Up 6 minutes k8s_nginx.d9a10343_nginx_default_eb1873c6-1c70

一.通过环境变量设置 apiVersion: v1 kind: Pod metadata: name: pod-env-tz spec: containers: - name: ngx image: nginx:latest imagePullPolicy: IfNotPresent env: - name: TZ value: Asia/Shanghai 二.通过挂载主机时区文件设置 apiVersion: extensions/v1beta1 kind: Deployment metadat

kubernetes yaml文件解析 # yaml格式的pod定义文件完整内容: apiVersion: v1 #必选,版本号,例如v1 kind: Pod #必选,Pod metadata: #必选,元数据 name: string #必选,Pod名称 namespace: string #必选,Pod所属的命名空间 labels: #自定义标签 - name: string #自定义标签名字 annotations: #自定义注释列表 - name: string spec: #必选,Po

什么是Pod Pod是可以创建和管理Kubernetes计算的最小可部署单元.一个Pod代表着集群中运行的一个进程. Pod就像是豌豆荚一样,它由一个或者多个容器组成(例如Docker容器),它们共享容器存储.网络和容器运行配置项.Pod中的容器总是被同时调度,有共同的运行环境.你可以把单个Pod想象成是运行独立应用的“逻辑主机”——其中运行着一个或者多个紧密耦合的应用容器——在有容器之前,这些应用都是运行在几个相同的物理机或者虚拟机上. 尽管kubernetes支持多种容器运行时,但是Dock

kubernetes yaml格式的Pod配置文件 # yaml格式的pod定义文件完整内容: apiVersion: v1 #必选,版本号,例如v1 kind: Pod #必选,Pod metadata: #必选,元数据 name: string #必选,Pod名称 namespace: string #必选,Pod所属的命名空间 labels: #自定义标签 - name: string #自定义标签名字 annotations: #自定义注释列表 - name: string spec:

1,创建PersistentVolume kind: PersistentVolume apiVersion: v1 metadata: name: task-pv-volume labels: type: local spec: storageClassName: manual capacity: storage: 10Gi accessModes: - ReadWriteOnce hostPath: path: "/mnt/data" 执行上面配置文件后PersistentVolu

第一章.什么是kube-controller-manager? Controller Manager 由 kube-controller-manager 和 cloud-controller-manager 组成, 是Kubernetes 的大脑, 它通过 apiserver 监控整个集群的状态, 并确保集群处于预期的工作状态. kube-controller-manager 由一系列的控制器组成 Replication Controller Node Controller CronJob Co

第一章.前言 在上一篇博客中,我们大致简述了一般情况下资源清单的格式,以及如何获得清单配置的命令帮助,下面我们再讲解下清单中spec字段中比较常见的字段及其含义 第二章.常用字段讲解 spec.containers <[]object> spec.containers <[]object> spec.containers.name <string> #pod的名称,必须字段,名称唯一且对象创建后不可以被修改 spec.containers.image <strin