I use below bash script to convert RGB to YCbCr601 and YCbCr709 on MacOsx, but the result is the same:
PNGNAME="input.png"
YUVNAME="image.yuv"
YUVNAME709="image709.yuv"
OUTNAME="result.png"
W=8
H=8
convert -size ${W}x${H} xc:#008800 $PNGNAME
convert $PNGNAME -depth 8 -colorspace Rec601YCbCr yuv:$YUVNAME
echo "601"
od -v -t u1 $YUVNAME
convert $PNGNAME -depth 8 -colorspace Rec709YCbCr yuv:$YUVNAME709
echo "709"
od -v -t u1 $YUVNAME709
Output:
601
0000000 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
0000020 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
0000040 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
0000060 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
0000100 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82
0000120 71 71 71 71 71 71 71 71 71 71 71 71 71 71 71 71
0000140
709
0000000 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
0000020 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
0000040 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
0000060 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
0000100 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82 82
0000120 71 71 71 71 71 71 71 71 71 71 71 71 71 71 71 71
0000140
I think ImageMagick is doing the colourspace conversion correctly, and you will see that if you run these two commands:
convert -depth 8 xc:'#008800' -colorspace Rec601YCbCr txt:
# ImageMagick pixel enumeration: 1,1,65535,rec601ycbcr
0,0: (20510.2,21189.7,18134) #505247 rec601ycbcr(80,82,71)
convert -depth 8 xc:'#008800' -colorspace Rec709YCbCr txt:
# ImageMagick pixel enumeration: 1,1,65535,rec709ycbcr
0,0: (24996.2,19296.5,16894.4) #614B42 rec709ycbcr(97,75,66)
The issue is that when you specify the output as yuv:FILENAME, that causes an implicit colourspace conversion back to Rec601, regardless of what it is at the moment.
Related
I have the following output when running kubectl get ingress:
NAME CLASS HOSTS ADDRESS PORTS AGE
ingress-svc nginx localdev.me 192.168.49.2 80 32m
and under vs code in codespaces, I see about 5 port forwarded ports that I can access from a browser that have processes that look like this:
/usr/bin/docker-proxy -proto tcp -host-ip 127.0.0.1 -host-port 49157 -container-ip 192.168.49.2 -container-port 22
I was wondering how I can configure the one with port 80 to some external port that I can access from the browser. Thank you.
we have a strange effect using Delphi XE8 with FastMM4 (Version 4.992) in FullDebugMode.
To reproduce the effect, just create a new TForm application, put FastMM4 in the first line of the DPR file,
put a Button on the Form and put the following code in the clickhandler:
(You need to have FastMM 4 installed, FullDebugMode must be enabled in the FastMM4Options.inc file and the
FullDebugMode.dll has to be in the output folder of your programm!)
procedure TForm3.Button4Click(Sender: TObject);
var
dm: tdatamodule;
doc: txmldocument;
begin
//this causes the messagebox to be shown directly after clicking the button.
//without it the box is shown when the program is exited.
FastMM4.FullDebugModeScanMemoryPoolBeforeEveryOperation := true;
//prepare a xml document
dm := tdatamodule.create(nil);
doc := txmldocument.create(dm);
doc.LoadFromXml('<?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?><root/>');
//doc.Active := true; //no need to set active to true. doc is already active at this point!
//the following does matter. ChildNodes needs to be accessed twice!
//doc.DocumentElement.ChildNodes.FindNode('first');
//doc.DocumentElement.ChildNodes.FindNode('second');
//alternative access:
doc.DocumentElement.ChildNodes.count; //first access to ChildNodes
doc.DocumentElement.ChildNodes.count; //second access to ChildNodes
//this does matter. if doc stays active then there is no problem!
doc.Active := false; //active needs to be set to false!
//doc.free; //doesn't matter if doc is freed manually. doc will be freed when datamodule is freed. problem occurs either way.
dm.free;
end;
When you click the button, FastMM4 will show a large messagebox with the following report:
FastMM has detected an error during a free block scan operation. FastMM detected that a block has been modified after being freed.
Modified byte offsets (and lengths): 80(1)
The previous block size was: 228
This block was previously allocated by thread 0xC74, and the stack trace (return addresses) at the time was:
406C46 [System.pas][System][#GetMem$qqri][4565]
407A73 [System.pas][System][TObject.NewInstance$qqrv][15975]
5DF25D [Xml.XMLDoc.pas][Xml.XMLDoc][Xmldoc.TXMLDocument.NewInstance$qqrv][2368]
408202 [System.pas][System][#ClassCreate$qqrpvzc][17290]
5DF116 [Xml.XMLDoc.pas][Xml.XMLDoc][Xmldoc.TXMLDocument.$bctr$qqrp25System.Classes.TComponent][2344]
5E2094 [Unit3.pas][Unit3][TForm3.Button4Click$qqrp14System.TObject][47]
407E6F [System.pas][System][#IsClass$qqrxp14System.TObjectp17System.TMetaClass][16465]
51EB39 [Vcl.Controls.pas][Vcl.Controls][Controls.TControl.Click$qqrv][7361]
535CF3 [Vcl.StdCtrls.pas][Vcl.StdCtrls][Stdctrls.TCustomButton.Click$qqrv][5327]
536801 [Vcl.StdCtrls.pas][Vcl.StdCtrls][Stdctrls.TCustomButton.CNCommand$qqrr26Winapi.Messages.TWMCommand][5788]
51E5C8 [Vcl.Controls.pas][Vcl.Controls][Controls.TControl.WndProc$qqrr24Winapi.Messages.TMessage][7245]
The block was previously used for an object of class: TXMLDocument
The allocation number was: 650
The block was previously freed by thread 0xC74, and the stack trace (return addresses) at the time was:
406C62 [System.pas][System][#FreeMem$qqrpv][4613]
407A91 [System.pas][System][TObject.FreeInstance$qqrv][15984]
40824D [System.pas][System][#ClassDestroy$qqrxp14System.TObject][17333]
5DF241 [Xml.XMLDoc.pas][Xml.XMLDoc][Xmldoc.TXMLDocument.$bdtr$qqrv][2363]
4C3661 [System.Classes.pas][System.Classes][Classes.TComponent.DestroyComponents$qqrv][15648]
4C3100 [System.Classes.pas][System.Classes][Classes.TComponent.$bdtr$qqrv][15445]
4C5543 [System.Classes.pas][System.Classes][Classes.TDataModule.$bdtr$qqrv][16694]
407B97 [System.pas][System][TObject.Free$qqrv][16052]
5E20F2 [Unit3.pas][Unit3][TForm3.Button4Click$qqrp14System.TObject][63]
51EB39 [Vcl.Controls.pas][Vcl.Controls][Controls.TControl.Click$qqrv][7361]
535CF3 [Vcl.StdCtrls.pas][Vcl.StdCtrls][Stdctrls.TCustomButton.Click$qqrv][5327]
The current thread ID is 0xC74, and the stack trace (return addresses) leading to this error is:
416526 [fastmm4.pas][FastMM4][InternalScanMemoryPool$qqruiui][10018]
416601 [fastmm4.pas][FastMM4][ScanMemoryPoolForCorruptions$qqrv][10092]
4161DF [fastmm4.pas][FastMM4][DebugFreeMem$qqrpv][9761]
406C62 [System.pas][System][#FreeMem$qqrpv][4613]
407A91 [System.pas][System][TObject.FreeInstance$qqrv][15984]
40824D [System.pas][System][#ClassDestroy$qqrxp14System.TObject][17333]
407B8A [System.pas][System][TObject.$bdtr$qqrv][16044]
40D5DD [System.pas][System][TInterfacedObject._Release$qqsv][37311]
40D4B7 [System.pas][System][#IntfClear$qqrr44System.%DelphiInterface$17System.IInterface%][36327]
40B189 [System.pas][System][#FinalizeArray$qqrpvt1ui][31704]
40B079 [System.pas][System][#FinalizeRecord$qqrpvt1][31407]
Current memory dump of 256 bytes starting at pointer address 7EA18B60:
98 72 5F 00 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 7F 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
80 80 80 80 BD 4A 52 7A 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 00 00 00 00 00 00 00 00
˜ r _ . € € € € € € € € € € € € € € € € € € € € € € € € € € € €
€ € € € € € € € € € € € € € € € € € € € € € € € € € € € € € € €
€ € € € € € € € € € € € € € € € € € € € € € € € € € € € € € €
€ € € € € € € € € € € € € € € € € € € € € € € € € € € € € € € €
€ € € € € € € € € € € € € € € € € € € € € € € € € € € € € € € €
€ € € € € € € € € € € € € € € € € € € € € € € € € € € € € € € €
€ € € € € € € € € € € € € € € € € € € € € € € € € € € € € € € €
€ € € € ½ J R z € € € € € € € € € € € € € € € € . . . . . . . .
If we interpret this correctly, then FastMM is telling us, that the Memory of the TXMLDocument Object
has been modified, after it was freed.
"Some Code" seems to have written the $7F in the middle of all these $80 in the memoryblock of the TXMLDocument
that has already been freed.
This does happen only if ChildNodes is accessed twice (!) and if the Active property of the TXMLDocument is set to false
before the Object is freed!
Questions:
Can someone explain what is going on here?
is setting TXMLDocument.Active to false generally considered wrong or "bad"? (Is it known to cause Problems?)
are we making some other mistake here?
is this a problem in FastMM4?
is this a problem in TXMLDocument?
Additional observation:
If the TXMLDocument is freed without active being set to false, then there is no problem.
If we look at the destructor of TXMLDocument we see that there is some additional code before
active is set to false there:
destructor TXMLDocument.Destroy;
begin
Destroying;
if FOwnerIsComponent and Active and Assigned(FDocumentNode) and (FRefCount > 1) then //additional code
(FDocumentNode as IXMLNodeAccess).ClearDocumentRef; //additional code
SetActive(False);
FreeAndNil(FXMLStrings);
inherited;
end;
Now, if we modify our own examplecode and call
(FDocumentNode as IXMLNodeAccess).ClearDocumentRef;
before setting active to false, then the problem is gone!
Code would look something like this:
type
TMyXMLDocument = class(TXMLDocument);
procedure TForm3.Button4Click(Sender: TObject);
var
dm: tdatamodule;
doc: txmldocument;
begin
FastMM4.FullDebugModeScanMemoryPoolBeforeEveryOperation := true;
dm := tdatamodule.create(nil);
doc := txmldocument.create(dm);
doc.LoadFromXml('<?xml version="1.0" encoding="ISO-8859-1" standalone="yes"?><root/>');
doc.DocumentElement.ChildNodes.count;
doc.DocumentElement.ChildNodes.count;
(TMyXMLDocument(doc).GetDocumentElement as IXMLNodeAccess).ClearDocumentRef; //<-- with this additional hack the problem is gone!
doc.Active := false; //no more problem!
dm.free;
end;
When calling methods/functions that return interfaces, the compiler implicitly generates variables to put these results into. They live until the end of the method and are then being finalized/cleared.
In your case doc.DocumentElement.ChildNodes does 2 method calls that return interfaces. Now when you destroy the TXMLDocument instance these implicit variables still point to some memory and due to the _Release call being made when the compiler generated code calls IntfClear they call into some method that has no object anymore - FastMM is able to track and report that.
So this mentioned call is translated into this:
var
...
nodes1: IXMLNodeList;
node1: IXMLNode;
nodes2: IXMLNodeList;
node2: IXMLNode;
begin
...
node1 := doc.DocumentElement;
nodes1 := node1.ChildNodes;
nodes1.count;
node2 := doc.DocumentElement;
nodes2 := node2.ChildNodes;
nodes2.count;
dm.free;
nodes1 := nil;
node1 := nil;
nodes2 := nil;
node2 := nil; // <- boom
In many cases this error does not manifest without using FastMM unless the previously deallocated memory was not being reused for another allocation which then results in weird AVs.
Rule of thumb: do not destroy instances that are referenced by some interface in the same scope as this might lead to implicitly created interface variables still pointing to them.
I am creating a new component, which inherits from TClientDataSet and it causes a memory leak. I've created a demo to reproduce the error (without need to share myCustomComponent). How can i solve this memory leak problem?
procedure TForm1.Button1Click(Sender: TObject);
begin
ClientDataSet1.Close;
ClientDataSet1.Tag := 1;
ClientDataSet1.Open;
end;
procedure TForm1.ClientDataSet1BeforeOpen(DataSet: TDataSet);
begin
if ClientDataSet1.Tag = 1 then
begin
ClientDataSet1.Tag := 0;
ClientDataSet1.Fields.Clear;
ClientDataSet1.FieldDefs.Clear;
ClientDataSet1.FieldDefs.Add('Collection', ftString, 50);
ClientDataSet1.FieldDefs.Find('Collection').CreateField(ClientDataSet1);
ClientDataSet1.CreateDataSet;
end;
end;
FastMM Event Log File:
--------------------------------2017/6/19 12:00:21--------------------------------
A memory block has been leaked. The size is: 68
This block was allocated by thread 0x4FA8, and the stack trace (return addresses) at the time was:
418CD6 [FastMM4.pas][FastMM4][DebugAllocMem$qqri][9900]
407276 [System.pas][System][AllocMem$qqri][4557]
65F91B [Datasnap.DBClient.pas][Datasnap.DBClient][Dbclient.TCustomClientDataSet.AllocKeyBuffers$qqrv][3965]
6598AE [Datasnap.DBClient.pas][Datasnap.DBClient][Dbclient.TCustomClientDataSet.InternalOpen$qqrv][1514]
623BC8 [Data.DB.pas][Data.DB][Db.TDataSet.DoInternalOpen$qqrv][12527]
623C77 [Data.DB.pas][Data.DB][Db.TDataSet.OpenCursor$qqro][12556]
65885B [Datasnap.DBClient.pas][Datasnap.DBClient][Dbclient.TCustomClientDataSet.OpenCursor$qqro][1282]
623B2F [Data.DB.pas][Data.DB][Db.TDataSet.SetActive$qqro][12508]
62396B [Data.DB.pas][Data.DB][Db.TDataSet.Open$qqrv][12464]
65BE16 [Datasnap.DBClient.pas][Datasnap.DBClient][Dbclient.TCustomClientDataSet.CreateDataSet$qqrv][2342]
706827 [Unit1.pas][Unit1][TForm1.ClientDataSet1BeforeOpen$qqrp16Data.Db.TDataSet][64]
The block is currently used for an object of class: Unknown
The allocation number is: 1092
Current memory dump of 256 bytes starting at pointer address 7EF776F0:
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F1 7F B4 7C
80 80 80 80 80 80 80 80 00 00 00 00 C1 70 F7 7E 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
73 04 00 00 D6 8C 41 00 76 72 40 00 1B F9 65 00 AE 98 65 00 C8 3B 62 00 77 3C 62 00 5B 88 65 00
2F 3B 62 00 6B 39 62 00 F4 65 70 00 D5 A7 53 00 A8 4F 00 00 A8 4F 00 00 AA 72 40 00 BE F5 60 00
AF F9 65 00 FA 9A 65 00 B8 3C 62 00 06 8C 65 00 9C 3B 62 00 F7 31 62 00 3C 8B 41 00 51 8B 41 00
29 7A 65 00 3C 00 00 00 00 00 00 00 69 F3 D9 86 E4 FB 71 00 80 80 80 80 80 80 80 80 80 80 80 80
80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . ñ ´ |
€ € € € € € € € . . . . Á p ÷ ~ . . . . . . . . . . . . . . . .
s . . . Ö Œ A . v r # . . ù e . ® ˜ e . È ; b . w < b . [ ˆ e .
/ ; b . k 9 b . ô e p . Õ § S . ¨ O . . ¨ O . . ª r # . ¾ õ ` .
¯ ù e . ú š e . ¸ < b . . Œ e . œ ; b . ÷ 1 b . < ‹ A . Q ‹ A .
) z e . < . . . . . . . i ó Ù † ä û q . € € € € € € € € € € € €
€ € € € € € € € € € € € € € € € € € € € € € € € € € € € € € € €
When trying #victoria 's code i get below error (althoug ReportMemoryLeaksOnShutDown does not raise anything) from fastMM then I realised FastMM confused me. I've reintroduced Open method and moved this code to there (without calling inherited or Open) and ReportMemoryLeaksOnShuntdown shows no leak but i could not understand why FastMM raises.
A memory block has been leaked. The size is: 68
This block was allocated by thread 0x4918, and the stack trace (return addresses) at the time was:
4DB29E54
4DB28419
4DB21AA9
4DB1FB5B
7711F11C [VirtualQuery]
33B8FD9 [GetFrameBasedStackTrace]
33B901C [GetFrameBasedStackTrace]
77983431 [Unknown function at RtlQueryPerformanceCounter]
33B9336 [GetRawStackTrace]
417A0E [FastMM4.pas][FastMM4][CalculateHeaderCheckSum$qqrp29Fastmm4.TFullDebugBlockHeader][9080]
417A1D [FastMM4.pas][FastMM4][UpdateHeaderAndFooterCheckSums$qqrp29Fastmm4.TFullDebugBlockHeader][9090]
The block is currently used for an object of class: Unknown
The allocation number is: 1060
Current memory dump of 256 bytes starting at pointer address 7EF76FA0:
3C 00 B4 4D 08 00 00 00 00 00 00 00 00 00 00 00 3F 00 00 00 00 80 80 80 80 80 80 80 80 80 80 80
80 80 80 80 80 80 80 80 43 00 80 80 80 80 80 80 80 80 80 80 80 80 80 80 01 00 00 00 0F 00 00 00
8C A3 AB 60 80 80 80 80 00 00 00 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
45 04 00 00 E8 A1 40 00 A3 AC 40 00 B5 F6 40 00 A0 BD 65 00 79 68 70 00 D5 A7 53 00 47 1F 55 00
55 2A 55 00 65 A2 53 00 38 70 3F 75 DD B4 04 74 18 49 00 00 18 49 00 00 AA 72 40 00 85 A2 40 00
3B BE 65 00 79 68 70 00 D5 A7 53 00 47 1F 55 00 55 2A 55 00 65 A2 53 00 38 70 3F 75 DD B4 04 74
89 B5 04 74 1B 00 00 00 E9 FD 01 00 04 D3 19 CB E4 FB 71 00 80 80 80 80 80 80 80 80 80 80 80 80
80 80 80 80 80 80 80 80 80 80 80 FB 2C E6 34 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80 80
< . ´ M . . . . . . . . . . . . ? . . . . € € € € € € € € € € €
€ € € € € € € € C . € € € € € € € € € € € € € € . . . . . . . .
Œ £ « ` € € € € . . . . . . . . . . . . . . . . . . . . . . . .
E . . . è ¡ # . £ ¬ # . µ ö # . ½ e . y h p . Õ § S . G . U .
U * U . e ¢ S . 8 p ? u İ ´ . t . I . . . I . . ª r # . … ¢ # .
; ¾ e . y h p . Õ § S . G . U . U * U . e ¢ S . 8 p ? u İ ´ . t
‰ µ . t . . . . é ı . . . Ó . Ë ä û q . € € € € € € € € € € € €
€ € € € € € € € € € € û , æ 4 € € € € € € € € € € € € € € € € €
Do not define and create your dataset in the BeforeOpen event. To create (and open) in-memory dataset do:
procedure TForm1.ButtonCreateClick(Sender: TObject);
begin
ClientDataSet1.Close;
ClientDataSet1.FieldDefs.Clear;
ClientDataSet1.FieldDefs.Add('ID', ftInteger);
ClientDataSet1.FieldDefs.Add('Collection', ftString, 50);
ClientDataSet1.CreateDataSet;
end;
To add record do:
procedure TForm1.ButtonAppendClick(Sender: TObject);
begin
ClientDataSet1.Append;
ClientDataSet1.FieldByName('ID').AsInteger := 1;
ClientDataSet1.FieldByName('Collection').AsString := 'My collection';
ClientDataSet1.Post;
end;
To edit current record do:
procedure TForm1.ButtonUpdateClick(Sender: TObject);
begin
ClientDataSet1.Edit;
ClientDataSet1.FieldByName('Collection').AsString := 'My collection upd.';
ClientDataSet1.Post;
end;
My manifest is as follows:
1 apiVersion: v1
2 kind: Pod
3 metadata:
4 name: myapp
5 spec:
6 containers:
7 - name: myapp
8 image: "myapp"
9 ports:
10 - containerPort: 3000
11 command: ["bash"]
12 args: ["-c", "sleep 999999"]
13 imagePullSecrets:
14 - name: regsecret
15 volumeMount:
16 - name: "secret-volume"
17 mountPath: "/etc/udev"
18 readOnly: true
19 volumes:
20 - name: "secret-volume"
21 secret:
22 - name: "myappsecret"
It produces the following error:
error validating data: [found invalid field volumeMount for v1.PodSpec, field spec.volumes[0].secret: expected object of type map[string]interface{}, but the actual type is []interface {}];
Why is volumeMount invalid? It seems like it is stated here https://kubernetes.io/docs/resources-reference/v1.5/#volume-v1 that there is such directive.
Also I don't really understand how to specify the secret as a mount. Tried several things including a suggestion here: https://github.com/kubernetes/kubernetes/issues/4710
Turns out volumeMount needs to be under the containers directive and slight change to the secret volume structure was necessary:
1 apiVersion: v1
2 kind: Pod
3 metadata:
4 name: myapp
5 spec:
6 containers:
7 - name: myapp
8 image: "myapp"
9 ports:
10 - containerPort: 3000
11 command: ["bash"]
12 args: ["-c", "sleep 999999"]
13 volumeMounts:
14 - name: "secret-volume"
15 mountPath: "/etc/secret-volume"
16 readOnly: true
17 imagePullSecrets:
18 - name: regsecret
19 volumes:
20 - name: "secret-volume"
21 secret:
22 secretName: "myappsecret"
I'm trying to run a docker container on Google Container-optimized VM in GCE.
Here is my dockerfile. I built a container image and push it to gcr.io.
FROM nginx:1.9
COPY config /etc/nginx
And I wrote a container manifest file.
version: v1beta2
containers:
- name: test
image: gcr.io/myproject/test
ports:
- name: http
hostPort: 80
containerPort: 80
- name: https
hostPort: 443
containerPort: 443
I deployed to GCE with the manifest file, but port binding was not as I had expected. Why did the host port 80 and 443 redirect to google_containers/pause instead of myproject/test?
local$ gcloud compute instance create test \
--image container-vm \
--metadata-from-file google-container-manifest=container.yaml \
--zone us-central1-b \
--machine-type f1-micro \
--tags http-server,https-server
local$ gcloud compute ssh --zone us-central1-b test
test$ sudo docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
818828ccc2c6 gcr.io/myproject/test:latest "nginx -g 'daemon of 23 seconds ago Up 22 seconds k8s_test.9de3822_7f9f8ecace94a22b2bea59ee14f3bcd0-test_df40d10c4dfa4
f40d10c4dfa4 gcr.io/google_containers/pause:0.8.0 "/pause" 32 seconds ago Up 31 seconds 0.0.0.0:80->80/tcp, 0.0.0.0:443->443/tcp k8s_POD.c6ce2a78_7f9f8ecace94a22b2bea59ee14f3bcd0-test_default_7f9f8ecace94a22b2bea59ee14f3bcd0-test_64d51838
I had updated version of the manifest v1beta2 to v1 (v1beta3) and tried it again. The result of port binding seems to be same as previous one, but the container can communicate with external network through port 80 and 443.
version:1
kind: Pod
spec:
restartPolicy: Always
dnsPolicy: Default
containers:
- name: test
image: gcr.io/myproject/test
imagePullPolicy: Always
ports:
- name: http
hostPort: 80
containerPort: 80
protocol: TCP
- name: https
hostPort: 443
containerPort: 443
protocol: TCP