kubernetes启动pod，pod状态一直不正常_--pod-infra-container-image-CSDN博客

https://blog.csdn.net/qq_19550657/article/details/80319329

kubernetes启动pod，pod状态一直不正常，查看pod状态显示

image pull failed for registry.access.redhat.com/rhel7/pod-infrastructure:latest, this may be because there are no credentials on this request. details: (open /etc/docker/certs.d/registry.access.redhat.com/redhat-ca.crt: no such file or directory)

按照网上所说的解决方案：yum install *rhsm* -y

Failed to create pod infra container: ImagePullBackOff; Skipping pod "redis-master-jj6jw_default(fec25a87-cdbe-11e7-ba32-525400cae48b)": Back-off pulling image "registry.access.redhat.com/rhel7/pod-infrastructure:latest

解决方法：试试通过手动下载

docker pull registry.access.redhat.com/rhel7/pod-infrastructure:latest

docker pull 是还是报错

open /etc/docker/certs.d/registry.access.redhat.com/redhat-ca.crt: no such file or directory

查看下redhat-ca.crt确实不存在，registry.access.redhat.com/rhel7/pod-infrastructure:latest默认是https下载。

最终解决方案：

1.docker search pod-infrastructure

INDEX NAME DESCRIPTION STARS OFFICIAL AUTOMATED
docker.io docker.io/openshift/origin-pod The pod infrastructure image for OpenShift 3 8
docker.io docker.io/davinkevin/podcast-server Container around the Podcast-Server Applic... 5
docker.io docker.io/infrastructureascode/aws-cli Containerized AWS CLI on alpine to avoid r... 4 [OK]
docker.io docker.io/newrelic/infrastructure Public image for New Relic Infrastructure. 3
docker.io docker.io/infrastructureascode/uwsgi uWSGI application server 2 [OK]
docker.io docker.io/infrastructureascode/serf A tiny Docker image with HashiCorp Serf us... 1 [OK]
docker.io docker.io/mosquitood/k8s-rhel7-pod-infrastructure 1
docker.io docker.io/podigg/podigg-lc-hobbit A HOBBIT dataset generator wrapper for PoDiGG 1 [OK]
docker.io docker.io/tianyebj/pod-infrastructure registry.access.redhat.com/rhel7/pod-infra... 1
docker.io docker.io/w564791/pod-infrastructure latest 1
docker.io docker.io/infrastructureascode/hello-world A tiny "Hello World" web server with a hea... 0 [OK]

找到可用的进行pull到本地。

docker run -d -p 5000:5000 --restart always --name registry registry:2

2.docker pull docker.io/tianyebj/pod-infrastructure

3.docker tag pod-infrastructure 10.30.30.126:5000/pod-infrastructure

其中10.30.30.126是本机的IP，pull下来之后push到本机的私有仓库。

服务端：

vim /etc/sysconfig/docker

客户端：

vim /etc/sysconfig/docker

4.docker push 10.30.30.126:5000/pod-infrastructure

5.vi /etc/kubernetes/kubelet

修改 KUBELET_POD_INFRA_CONTAINER="--pod-infra-container-image=10.30.30.126:5000/pod-infrastructure:latest"

6.重启

systemctl restart kube-apiserver
systemctl restart kube-controller-manager
systemctl restart kube-scheduler
systemctl restart kubelet

systemctl restart kube-proxy

7. kubectl get pods 查看之前的pods已经正常状态Running

注意：nexus 的时候就会不行，nexus默认是https需要认证，kubectl create -f aaa.yaml 会报错，就是由于pod-infrastructure 需要认证没有ca。但是registry:2.0 不需要认证。

Docker守护进程可以用标志站起来 --insecure-registry跳过对自签名证书的验证。但版nexus不支持使用该标志，因为它会产生已知的错误和其他实现问题。

https://help.sonatype.com/repomanager3/private-registry-for-docker/ssl-and-repository-connector-configuration

https://help.sonatype.com/repomanager3/private-registry-for-docker/authentication

https://support.sonatype.com/hc/en-us/articles/217542177?_ga=2.91895775.435346500.1528882136-1736321326.1516268459

vim /etc/kubernetes/kubelet

背景

像Nexus Repository Manager 3这样的私人Docker注册中心将需要用户进行身份验证才能发布泊坞窗图像。

为了使用身份验证，Docker守护程序实施强制注册表连接使用HTTPS。

默认情况下，Nexus 3未配置HTTPS连接器，因为配置它需要手动生成和配置SSL证书。

出于测试目的，管理员可能希望为Nexus HTTPS连接器使用自签名TLS证书。

尽管自签名证书可以加密HTTP通信并快速生成，但由于证书身份尚未由第三方证书颁发机构（CA）进行签名/验证，所以通常认为它们不可信。

为了解决Docker Daemon问题，考虑到Nexus HTTPS的不可信赖性，守护进程会有一个名为--insecure-registry的选项。通过将Nexus主机名和端口标记为不安全，docker守护程序不会验证安全连接的可信性。其目的是为了避免使用不可信证书时通常会发生的错误。

但是，-- insecure-registry 标志具有许多不需要的副作用，并且可能会导致不会遇到的晦涩错误。

由于定义不明确， Sonatype不能推荐使用Docker --insecure-registry 标志。

如何生成可以由Docker守护程序信任的自签名证书

而不是通过使用--insecure-registry来告诉docker守护进程不验证自签名证书，更好的做法是告诉它明确信任自签名证书。

Docker提供了描述使用openssl生成CA和服务器自签名证书的文档。但是，这些说明可能会导致Docker仍不会信任自签名证书的错误消息。另外Openssl在所有系统上都没有实现。

下面列出的步骤是使用Java keytool以平台中立的方式为Nexus生成自签名服务器证书的另一种可靠方法。这些步骤可用于配置Docker以显式信任与Nexus Repository Manager的连接。

第1步：使用keytool为Nexus生成自签名服务器证书

首先确定Docker将使用的Nexus的主机名和外部可访问的IP地址。主机名和IP地址将嵌入自签名证书中，以便主机名证书验证不会失败。

在Nexus主机上，转到<AppDir> / etc / ssl目录。为Nexus生成公用密钥对，以用于任何HTTPS连接器。

在下面的命令中：

将$ {NEXUS_DOMAIN}替换为Nexus主机的DNS名称。主机名必须可以从运行Docker守护进程的主机解析。
将$ {NEXUS_IP_ADDRESS}替换为Nexus主机的IP地址。IP地址必须可以从运行Docker守护程序的主机路由到Nexus。

keytool -genkeypair -keystore keystore.jks -storepass密码-keypass密码-alias jetty -keyalg RSA -keysize 2048 -validity 5000 -dname“CN = *。$ {NEXUS_DOMAIN}，OU =示例，O = Sonatype，L =未指定， ST =未指定，C = US“-ext”SAN = DNS：$ {NEXUS_DOMAIN}，IP：$ {NEXUS_IP_ADDRESS}“-ext”BC = ca：true“

您最终应该在本地目录中创建一个名为keystore.jks的文件。CN值指定所谓的通配符证书，它将匹配任何子域。

第2步：配置Nexus以使用自签名服务器证书

对于3.0.x，请遵循在Nexus中启用SSL的先决条件。

对于3.1或更高版本，请参阅入站SSL - 配置通过HTTPS提供内容

特别是，确保SSLContextFactory配置为指向步骤1中生成的密钥库文件。确保这些设置存在于jetty-https.xml中：

Repository Manager 3.0.x示例： （<AppDir> /etc/jetty-https.xml）

<Set name =“KeyStorePath”> <Property name =“karaf.etc”/> / ssl / keystore.jks </ Set>
<Set name =“KeyStorePassword”> changeit </ Set>
<Set name =“KeyManagerPassword”> changeit </ Set>  
<Set name =“TrustStorePassword”> changeit </ Set>

Repository Manager 3.1.0和更新的示例：（<AppDir> /etc/jetty/jetty-https.xml）

<Set name =“KeyStorePath”> <Property name =“ssl.etc”/> / keystore.jks </ Set>
<Set name =“KeyStorePassword”> changeit </ Set>
<Set name =“KeyManagerPassword”> changeit </ Set> 
<Set name =“TrustStorePassword”> changeit </ Set>

重新启动Nexus以接收任何配置更改。

步骤3：配置Docker守护程序以信任证书

使用Oracle java`keytool`检索并打印在$ {NEXUS_DOMAIN}：$ {SSL_PORT}上运行的Nexus实例的Nexus服务器证书：

keytool -printcert -sslserver $ {NEXUS_DOMAIN}：$ {SSL_PORT} -rfc

这个命令将打印由包围的编码的证书-----BEGIN CERTIFICATE-----和-----END CERTIFICATE-----线。

如果您拥有对运行Docker守护程序的主机的超级用户访问权限，则最好的选择是在系统级别信任Nexus服务器证书。复制打印的证书并将其粘贴到文件位置，如下所述。

Docker 对基于unix的系统如何信任证书提出了一般建议，我们建议遵循他们的建议。

第二种选择是仅将Docker配置为以每个主机：端口为基础信任证书。Docker对于可以复制证书的位置提供了特定的建议，以便每台主机可以自动信任这些证书。缺点是对于每个Docker注册表主机：端口的访问，必须添加一个新的证书文件。

学习kubernetes中遇见的一些坑（持续更新）

一、权限问题

通过rc配置文件起pod，rc中配置了privileged为true，发现pod状态一直Running不起来，查看pod详情发现

    [root@docker tmp]# kubectl describe pods nfs-rc-acbo1
    Name:       nfs-rc-acbo1
    Namespace:  default
    Node:       duni-node2
    Labels:     role=nfs-server
    Status:     Pending
    IP:     
    Controllers:    ReplicationController/nfs-rc
    Containers:
      nfs-server:
        Image:          192.168.100.90:5000/nfs-data
        Port:           2049/TCP
        Volume Mounts:      <none>
        Environment Variables:  <none>
    Conditions:
      Type      Status
      PodScheduled  True 
    No volumes.
    QoS Class:  BestEffort
    Tolerations:    <none>
    Events:
      FirstSeen LastSeen    Count   From            SubobjectPath   Type        Reason          Message
      --------- --------    -----   ----            -------------   --------    ------          -------
      27s       27s     1   {default-scheduler }            Normal      Scheduled       Successfully assigned nfs-rc-acbo1 to duni-node2
      27s       27s     1   {kubelet duni-node2}            Warning     FailedValidation    Error validating pod nfs-rc-acbo1.default from api, ignoring: spec.containers[0].securityContext.privileged: Forbidden: disallowed by policy

解决：

修改所有node以及master节点的k8s配置文件 vim /etc/kubernetes/config

$ KUBE_ALLOW_PRIV="--allow-privileged=true"
$ systemctl restart kube-apiserver

二、pause k8s镜像下载失败

pod启动失败，查看pod详情(kubectl describe pods podname)

    Events:
      FirstSeen LastSeen    Count   From            SubobjectPath   Type        Reason      Message
      --------- --------    -----   ----            -------------   --------    ------      -------
      56s       56s     1   {default-scheduler }            Normal      Scheduled   Successfully assigned nfs-rc-fc2w8 to duni-node1
      11s       11s     1   {kubelet duni-node1}            Warning     FailedSync  Error syncing pod, skipping: failed to "StartContainer" for "POD" with ErrImagePull: "image pull failed for gcr.io/google_containers/pause-amd64:3.0, this may be because there are no credentials on this request.  details: (Get https://gcr.io/v1/_ping: dial tcp 74.125.203.82:443: i/o timeout)"

解决：

方法一：如果服务器可以访问外网，则可在docker daemon的启动参数中加上--insecure-registry gcr.io
1、修改docker配置文件(vim /etc/sysconfig/docker)

OPTIONS='--selinux-enabled --log-driver=journald --signature-verification=false --registry-mirror=https://olzwzeg2.mirror.aliyuncs.com --insecure-registry gcr.io'

2、重启docker服务

$ systemctl restart docker

方法二、

如果kubernetes集群在内网环境中，无法访问gcr.io网站，则可先通过一台能访问gcr.io的机器下载pause镜像，导出后再导入内网的docker私有镜像仓库中，并在kubelet的启动参数中加上--pod_infra_container_image，然后重启kubelet

一般google官方的镜像被墙了不能下载，我们都可以到阿里云或者DaoCloud下载，有人会同步google镜像的，下载后同步到自己的私有仓库

到docker hub 下载pause镜像

$ docker pull kubernetes/pause

假设你已搭建私有的镜像仓库地址为:192.168.10.12:5000，如何搭建自己的镜像私有仓库

修改pause镜像标签

$ docker tag docker.io/kubernetes/pause:latest 192.168.10.12:5000/google_containers/pause-amd64.3.0

上传镜像到私有仓库

$ docker push 192.168.10.12:5000/google_containers/pause-amd64.3.0

vim /etc/kubernetes/kubelet配置为：

KUBELET_ARGS="--pod_infra_container_image=192.168.10.12:5000/google_containers/pause-amd64.3.0"

重启kubelet

$ systemctl restart kubelet

三、pod删除了又重启

用kubectl run test --image=test_image启动的容器，删除pod后一直重启

解决：

详情：http://dockone.io/question/1076

四、磁盘空间不够，Dockerfile build失败

当我们制作docker镜像比较大，而制作镜像的机器磁盘空间不够大时，便会提示我们docker build失败

查看磁盘空间

df -h

查看缓存

free -h

清空缓存

echo 3 > /proc/sys/vm/drop_caches

查看docker镜像

docker images -a

删除docker镜像

du -h /var/lib/docker