Kubernetes – Synchronizing Date and Time in Pods Hosted in Own Datacenter

kubernetestime-synchronization

I am having issue with date and time in kubernetes cluster. My host time is sync using the ntp. Though i have synced it after configuring the cluster. Now all the pods created within my cluster will have wrong timezone. I found the issue is with the docker itself. As I am using CentOS 7 VMs which are over EXSi, it seems docker containers are taking UTC timezone from the exsi host rather then the centos i guess? Is there a way to fix this issue where new pods spawned will take the CentOS timezone rather then the EXSi host timezone? I could have use TZ env but for some docker base image like alpine, tzdate packages seems to be needed. So i don't want to rebuild the docker for some application which i can get prebuild out of the box like fluentd and such. Is there a way to fix it?

Thank You

Best Answer

As far as I know, the VMWware ESX/ESXi hosts setup guest virtual machines (VM) to sync the time with the host (or hypervisor).

Assuming that NTP is working on ESXi host, clocks on CentOS VM must be synced as well.

The clock in a container is the same as the host machine because it’s controlled by the kernel. In this case, the host machine is CentOS VM. Thus container's clocks shall be synced as well.

The timezone is controlled by the OS layer though and so may be different in the container. You can mount in the time zone file to overcome this.

Now all the pods created within my cluster will have wrong timezone.

As far as I understood that's exactly the issue you've found.

ESXi 5.5 and after uses UTC by default and it doesn't support changing the time zone.

Related Solutions

Docker – From docker containers to Google Kubernetes

Should the time come that I have 15 containers to manage, instead of 5, is there any merit in using Google Kubernetes?

If you run containers on a single server using the Docker daemon and its Remote API sounds appropriate.

If you need to run containers on more than one server, that's where orchestration solutions like Kubernetes, Docker swarm, Fleet, Mesos, Geard becomes useful.

My primary issue here is that 'dockerfiles' are completely different from pod configs.

Because they have different purposes:

Dockerfile specifies how to build a container image from a tree of sources
pod.yaml defines how to schedule (image, command line, volumes, port) a set of co-located containers (sharing network namespace, and volumes) on one of the node of your cluster.

You can see pods as a way to declarative specify a set of docker run --net=container:... -v ... -p ... commands.

Also, is there an 'official', or at least 'definitive', workflow to migrate from Docker containers to 'pods', the native unit of Kubernetes.

There is a small tool in kubernetes/contrib called podex that allow you to generate a pod manifest from image metadata stored in the public registry.

$ go get github.com/GoogleCloudPlatform/kubernetes/contrib/podex
$ podex google/nodejs-hello
id: nodejs-hello
kind: Pod
apiVersion: v1beta1
desiredState:
  manifest:
    version: v1beta2
    containers:
    - name: nodejs-hello
      image: google/nodejs-hello
      ports:
      - name: nodejs-hello-tcp-8080
        containerPort: 8080

Kubernetes (K8S): TCP clients waiting very long timeout on connection to a Service when there are no Pods serving its requests

A Service is an abstraction in Kubernetes which defines a logical set of Pods and a policy by which to access them. Technically, a Service is a type of Kubernetes resource that causes a proxy to be configured to forward requests to a set of pods.

In your case, your Redis Client connects directly to your Redis Pod using some firewall rules configured in a Service. Therefore, if the Service was untouched, connection problems may appear only on the Pod side or on the Client side. So, you need to look for configuration settings for them.

Best Answer

Related Solutions

Docker – From docker containers to Google Kubernetes

Kubernetes (K8S): TCP clients waiting very long timeout on connection to a Service when there are no Pods serving its requests

Related Topic