stratos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Imesh Gunaratne <im...@apache.org>
Subject Re: Stratos and Kuburnetes and docker support.
Date Sat, 04 Oct 2014 18:00:36 GMT
Great! Thanks for the clarification! The term "replicas" was bit confusing,
that's why.

On Tue, Sep 23, 2014 at 1:26 PM, Nirmal Fernando <nirmal070125@gmail.com>
wrote:

> Hi Imesh,
>
> On Tue, Sep 23, 2014 at 12:00 PM, Imesh Gunaratne <imesh@apache.org>
> wrote:
>
>> Regarding health monitoring in containers, as discussed the best approach
>> would be to use a well-known docker container monitoring tool such as
>> cAdvisor coupled with a cartridge agent instance per controller node.
>>
>
> Yes, using cAdvisor we can monitor the docker containers as brought out
> earlier too. Also, there's Heapster
> https://github.com/GoogleCloudPlatform/heapster which enables monitoring
> containers of a Kubernetes cluster.
>
>
>> Why do we use the term "replicas" for the Kubernetes control node
>> instances? Are we looking at providing HA for controller nodes rather than
>> treating them as a cluster of controller nodes.
>>
>
> Could you please explain what you meant by  'Kubernetes control node
> instances' ? Here what replicas imply is the number of pods generated from
> a pod template (so for a php cluster case, you will have a cluster of PHP
> pods (in this case only 1 container resides inside the pod) distributed
> across the Kubernetes cluster (a set of Kubernetes slaves)).
>
>>
>> On Tue, Sep 16, 2014 at 7:04 AM, Nirmal Fernando <nirmal070125@gmail.com>
>> wrote:
>>
>>> AFAIS Autoscaler's task is very simple in the container case. It just
>>> need to create a kubernetes replication controller with the minimum number
>>> of replicas initially via CC and need to update the number of replicas of
>>> the same kubernetes replication controller (again via CC) based on the
>>> health stats and make sure that the number of replicas are maintained under
>>> maximum replicas count.
>>>
>>>
>>> On Tue, Sep 16, 2014 at 3:20 PM, Lahiru Sandaruwan <lahirus@wso2.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Tue, Sep 16, 2014 at 2:57 PM, Lakmal Warusawithana <lakmal@wso2.com>
>>>> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Tue, Sep 16, 2014 at 1:53 PM, Lahiru Sandaruwan <lahirus@wso2.com>
>>>>> wrote:
>>>>>
>>>>>> Hi Akila,
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Tue, Sep 16, 2014 at 12:49 PM, Akila Ravihansa Perera <
>>>>>> ravihansa@wso2.com> wrote:
>>>>>>
>>>>>>> Hi Raj,
>>>>>>>
>>>>>>> We can use the same CEP stream to publish cartridge agent health
>>>>>>> stats. We can identify the instance type (container or VM type)
by
>>>>>>> retrieving member properties from the topology. But I don't think
we should
>>>>>>> be doing that.
>>>>>>>
>>>>>>> IMO, we should not publish cartridge agent health stats from
each
>>>>>>> and every container. It's better if we can have a global agent
per
>>>>>>> Kubernetes host instance to monitor the health of every container
and also
>>>>>>> in host instance itself. We can use a container monitoring agent
like
>>>>>>> cAdvisor to collect container health stats.
>>>>>>>
>>>>>>
>>>>>> This is a good model. We will anyway have an agent in docker host
as
>>>>>> it is a multi-tenant cartridge instance. Then we can improve same
agent to
>>>>>> take-care of it's docker instances. We might need to let it know
that it is
>>>>>> running in a docker host.
>>>>>>
>>>>>> Do you suggest we completely get rid of agent inside dockers?
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>>>
>>>>>>> +1 for having a separate CEP execution plan for handling Docker
>>>>>>> containers scenario.
>>>>>>>
>>>>>>> As for the ContainerClusterMonitor, we should clearly outline
the
>>>>>>> responsibilities of container monitor and VM monitor. Because
since we are
>>>>>>> using Kubernetes for managing the life-cycle of containers, most
of the
>>>>>>> tasks are already taken care of. For eg - we don't need to start
a new
>>>>>>> container if an existing containers fails since Kubernetes will
handle that
>>>>>>> failure.
>>>>>>>
>>>>>>
>>>>>> My concern of letting Kubernetes control minimum values is, it is
>>>>>> difficult to get the new member identified in Stratos side. Shall
we take
>>>>>> that control to Autoscaler as we do for VM clusters?
>>>>>>
>>>>>
>>>>> Here Stratos will defining the min container count, but Kubernetes
>>>>> will take care of up and running it.
>>>>>
>>>>
>>>> Stratos might keep a higher value for active instances list for few
>>>> minutes(until we get member fault for lost instance) in this case. It will
>>>> affect Autoscaling decision and active instances shown in UIs.
>>>>
>>>> That was my initial concern. But if the Kubernetes is very fast on this
>>>> HA action, it would be better to let Kubernetes handle it, as it would
>>>> increase Stratos HA ability as well.
>>>>
>>>> Thanks.
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>>>
>>>>>>> WDYT?
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> --
>>>>>> Lahiru Sandaruwan
>>>>>> Committer and PMC member, Apache Stratos,
>>>>>> Senior Software Engineer,
>>>>>> WSO2 Inc., http://wso2.com
>>>>>> lean.enterprise.middleware
>>>>>>
>>>>>> email: lahirus@wso2.com cell: (+94) 773 325 954
>>>>>> blog: http://lahiruwrites.blogspot.com/
>>>>>> twitter: http://twitter.com/lahirus
>>>>>> linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Lakmal Warusawithana
>>>>> Vice President, Apache Stratos
>>>>> Director - Cloud Architecture; WSO2 Inc.
>>>>> Mobile : +94714289692
>>>>> Blog : http://lakmalsview.blogspot.com/
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> --
>>>> Lahiru Sandaruwan
>>>> Committer and PMC member, Apache Stratos,
>>>> Senior Software Engineer,
>>>> WSO2 Inc., http://wso2.com
>>>> lean.enterprise.middleware
>>>>
>>>> email: lahirus@wso2.com cell: (+94) 773 325 954
>>>> blog: http://lahiruwrites.blogspot.com/
>>>> twitter: http://twitter.com/lahirus
>>>> linked-in: http://lk.linkedin.com/pub/lahiru-sandaruwan/16/153/146
>>>>
>>>>
>>>
>>>
>>> --
>>> Best Regards,
>>> Nirmal
>>>
>>> Nirmal Fernando.
>>> PPMC Member & Committer of Apache Stratos,
>>> Senior Software Engineer, WSO2 Inc.
>>>
>>> Blog: http://nirmalfdo.blogspot.com/
>>>
>>
>>
>>
>> --
>> Imesh Gunaratne
>>
>> Technical Lead, WSO2
>> Committer & PMC Member, Apache Stratos
>>
>
>
>
> --
> Best Regards,
> Nirmal
>
> Nirmal Fernando.
> PPMC Member & Committer of Apache Stratos,
> Senior Software Engineer, WSO2 Inc.
>
> Blog: http://nirmalfdo.blogspot.com/
>



-- 
Imesh Gunaratne

Technical Lead, WSO2
Committer & PMC Member, Apache Stratos

Mime
View raw message