On Tue, Sep 16, 2014 at 3:54 PM, Akila Ravihansa Perera <raviha...@wso2.com> wrote:
> 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? > yes, that what I also meant. > > @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 > -- Lakmal Warusawithana Vice President, Apache Stratos Director - Cloud Architecture; WSO2 Inc. Mobile : +94714289692 Blog : http://lakmalsview.blogspot.com/
