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/
