在单节点 kubernetes 集群上,我可以使用 'expose' cmd 公开服务,但是通过 create -f <svc.json-file> 失败

on single node kubernetes cluster i can expose a service with 'expose' cmd, but doing it via create -f <svc.json-file> fails

我正在设置一个单节点 k8s 集群进行测试,我们 运行 遇到了一个令人困惑的服务问题。我已将该示例提炼为部署 word press 服务之一,我可以使用 kubectl create -f wordpress-rc.json 然后进行公开。但是当我按照 kubectl create -f 创建 rep 控制器时,它失败了。我在下面显示所有 json 文件内容。

代表控制器:

{
  "kind": "ReplicationController",
  "apiVersion": "v1",
  "metadata": {
    "name": "wordpress",
    "labels": {
      "app": "wordpress"
    }
  },
  "spec": {
    "replicas": 1,
    "selector": {
      "app": "wordpress"
    },
    "template": {
      "metadata": {
        "labels": {
          "app": "wordpress"
        }
      },
      "spec": {
        "containers": [
          {
            "name": "wordpress",
            "image": "tutum/wordpress",
            "ports": [
              {
                "containerPort": 80,
                "name": "http-server",
                "protocol": "TCP"
              }
            ],
            "imagePullPolicy": "IfNotPresent"
           }
        ],
        "restartPolicy": "Always",
        "dnsPolicy": "ClusterFirst"
      }
    }
  }
}

服务:

{
  "kind": "Service",
  "apiVersion": "v1",
  "metadata": {
    "name": "wordpress",
    "labels": {
      "name": "wordpress"
    }
  },
  "spec": {
        "type": "LoadBalancer",
    "ports": [
      {
        "name":"wordpress1",
        "protocol":"TCP",
        "port": 80,
        "targetPort": 80
      }
    ],
    "selector": {
      "name": "wordpress"
    }
  }
}

工作命令序列

 alias kk kubectl
 kk create -f /tmp/wp-rc.json
 kubectl expose rc wordpress --type=LoadBalancer

命令序列失败

  alias kk kubectl
  kk create -f /tmp/wp-rc.json
  kk create -f /tmp/wp-service.json

我的问题是为什么服务定义不起作用,而暴露命令却起作用?

为了完整起见..这是我启动单节点 k8s 集群的方式。这是centos 7上的全部运行ning,b.t.w:

#   magic selinux context set command is required. for details, see: 
#
sudo chcon -Rt svirt_sandbox_file_t /var/lib/kubelet


docker run --net=host -d gcr.io/google_containers/etcd:2.0.12 /usr/local/bin/etcd --addr=127.0.0.1:4001 --bind-addr=0.0.0.0:4001 --data-dir=/var/etcd/data


docker run \
    --volume=/:/rootfs:ro \
    --volume=/sys:/sys:ro \
    --volume=/dev:/dev \
    --volume=/var/lib/docker/:/var/lib/docker:ro \
    --volume=/var/lib/kubelet/:/var/lib/kubelet:rw \
    --volume=/var/run:/var/run:rw \
    --net=host \
    --pid=host \
    --privileged=true \
    -d \
    gcr.io/google_containers/hyperkube:v1.0.1 \
    /hyperkube kubelet --containerized --hostname-override="127.0.0.1" --address="0.0.0.0" --api-servers=http://localhost:8080 --config=/etc/kubernetes/manifests

docker run -d --net=host --privileged gcr.io/google_containers/hyperkube:v1.0.1 /hyperkube proxy --master=http://127.0.0.1:8080 --v=2

sleep 20   # give everything time to launch

服务json文件使用了标签选择器name: wordpress,这与复制控制器的标签选择器app: wordpress不同。这意味着使用 json 文件创建的服务以 pods 为目标 name: wordpress 标签,但复制控制器以 app: wordpress 标签为目标 pod。这就是您使用 json 文件创建的服务未按预期工作的原因。

您可以使用 kubectl get svc wordpress -o yaml 来比较两个创建的服务。

此外,根据config best practice,建议先创建一个服务,然后再创建复制控制器:

Create a service before corresponding replication controllers so that the scheduler can spread the pods comprising the service. You can also create the replication controller without specifying replicas, create the service, then scale up the replication controller, which may work better in an example using progressive disclosure and may have benefits in real scenarios also, such as ensuring one replica works before creating lots of them)