Hi,

I think we lost that control once we decided to use Kubernetes to
manage containers. The whole idea of using Kubernetes is to starting,
destroying and maintaining HA within container cluster.

As for the agent health stats, there can be situations where
application level monitoring is required. But in that case, we will
have to deploy a customized agent and also custom CEP execution plans.

What I'm suggesting is to use Kubernetes host level global agent as
the default behavior for monitoring containers resource usage. Main
reason is to lower the foot print much as possible and to make the
agent light weight. That can be extended to per container model health
publishing if application level monitoring is required.

wdyt?

@Lahiru: I don't think we can get rid of per container agent model
since there are functionalities performed by the agent other than
publishing health stats. What we can do is to minimize the agent's
foot print.

@Raj: This is not implemented yet. But we should fix that.

Thanks.

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
>



-- 
Akila Ravihansa Perera
Software Engineer, WSO2

Blog: http://ravihansa3000.blogspot.com

Reply via email to