Hi Imesh,

On Tue, Sep 23, 2014 at 12:00 PM, Imesh Gunaratne <im...@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 <nirmal070...@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 <lahi...@wso2.com>
>> wrote:
>>
>>>
>>>
>>> On Tue, Sep 16, 2014 at 2:57 PM, Lakmal Warusawithana <lak...@wso2.com>
>>> wrote:
>>>
>>>>
>>>>
>>>> On Tue, Sep 16, 2014 at 1:53 PM, Lahiru Sandaruwan <lahi...@wso2.com>
>>>> wrote:
>>>>
>>>>> Hi Akila,
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Sep 16, 2014 at 12:49 PM, Akila Ravihansa Perera <
>>>>> raviha...@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: lahi...@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: lahi...@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/

Reply via email to